Re: Fwd: Let's move on our bug tracking system and git repository

[Jehan Pagès <jehan marmottard gmail com>]

Hi,

On Tue, Oct 25, 2016 at 12:52 PM, Tobias Mueller <muelli cryptobitch de> wrote:
> Hi.
>
> On Mo, 2016-10-24 at 10:44 +0200, Abel wrote:
> > I guess somebody has already broached the subject before,
> I don't remember any discussion, so your guess might be wrong ;-)
>
> > I get very frustrated when I have to look for some patch, submit a
> > bug or browse through the code using the current tools: bugzilla and
> > git.gnome.org.
> Can you elaborate?  Or even better, talk to the products involved, i.e.
> Bugzilla and cgit (is it?)?
>
>
> > We're in 2016 guys, why don't we move to a more modern and visual alternative?
> I think the main reason is that someone would have to do it which has
> not been the case so far.
> It's a bit more complicated than that, though, because it also needs to
> be maintained, updated, and possibly integrated into the rest of the
> infrastructure.
>
> >  I propose Gitlab as it's open source, we can install it in our servers, [...]
> How do you know that can install it?  I think it's more complicated
> than downloading their omnibus thing and running it.
> For example, it needs to be updated every so often.  Do they not do
> releases every month or so?  I currently don't see how this would be
> possible to do on our end.

It also depends on how they maintain their releases. Do they have any
long term releases with bug fixes?
If they don't, they might agree to start doing this if a big project
like GNOME wanted to install (though they are also a company so they
might prefer to sell support).

> >  it's robust and it has many good features as well as integrations.
> I like Gitlab and I tend to install it for the projects I work on. But
> I would wait for more real world exposure until I'd call it "robust".
> See, Trac was the new kid a few years ago. Until it became not
> fashionable anymore and people started to like Redmine. Now it's
> something else entirely.  While I understand that we ought to be open
> for modern tools, I also have the desire for keeping things stable.
> Especially given that the whole Web stuff is not our main expertise.

I have tried a bit gitlab on their main instance (gitlab.com) lately.
My first concern is that I find it quite slow. Maybe their server is
simply not adapted but that scares me a little. We'd need to make sure
the software can handle the users of GNOME (not a small userbase!).

Also does gitlab has all the features we need? Thing I can think of:
you cannot move bug reports accross projects, which is a very common
thing in GNOME and friends project (for instance someone opens a bug
report in GIMP, we investigate, it turns out the bug is actually in
some lib, and we move the bug report). Of course we can do without, by
creating a new bug report for instance (which we do when the
dependency project is not hosted by GNOME). But that kind of details
may make some of the workflow maybe less straightforward. Well I'd get
used to this particular change, but just saying…

More annoying is that gitlab has a completely wrong idea of a git
workflow (inspired by github) IMO. This whole forking business makes
everything complicated. On github in particular, I hate that I can't
simply upload a git-formatted patch. I have to make my own github
repository ("fork"), customize my remotes on my local repo, push, then
go "pull request" on the upstream. This is completely crazy. I mean,
having my own public repo could make sense for a project where I am a
huge contributor and also if I want to publicize my work before it is
upstream. But really that's an edge case. This workflow for 1-time
patches is terrible.
Moreover public repositories should not change history all the time.
But github/gitlab user (forked) repos are actually no more than
private repos which are public for no reasons. So users create them,
delete them, force-push them and so on, on a whim. This is a fucked-up
and messy workflow.
I see that gitlab at least does not prevent patch upload on the issue
tracker (github does!), so the good point is that normal patch
contribution is possible there. Still they are obviously encouraging
the github-style fork-everything workflow and that's bad (IMO). And
the uploaded patch does not benefit from any of the reviewing web UI!
Clicking on a patch only proposes me to download it. We'd be at a
clear functionality loss compared to bugzilla here.

Now some people say that it makes the reviewer/maintainer life easier
because they can merge directly from the web UI. Personally I am a
little scared because I saw many github projects just merge all and
everything this way without the maintainers even applying the patch on
their local repository first. Ok some patches, I can understand (typo
corrections and alike). But when it becomes more complicated, even if
first a visual review can simply be done on the web UI (and all seems
good there), I would usually still apply the patch and test it anyway.
Since I do so, pushing the commit in the end is much easier than going
back to my browser to click a button (which does prevent small
amending of the commits too). So I feel that the github/gitlab way of
making things said-to-be-easier for maintainers/reviewer is also
encouraging a lesser job quality.

Also having everyone fork every project means that GNOME will be
responsible for hosting dozens of forks for a given project, maybe
hundreds for projects with the most popularity (GIMP has 204 forks on
the github mirror, as I write). Well disk space is cheap nowadays, but
just saying it has to be taken into consideration. Of course, I guess
we will have to block the ability to create new repositories from
scratch (unless we want GNOME hosting to become a generic hosting,
which I think, we don't).

Now don't get me wrong. I appreciate some of github and gitlab
features. Their code reviewing UI is much better than bugzilla's for
one. Also having the bugtracker and the git web UI in a single place
is practical (and most probably makes "how to contribute to project"
easier). They have statistics and cool stuff.
But I also see a lot of issues which should not be ignored and
carefully weighted-in. I would personally appreciate a patched version
of gitlab where we only keep what interests us. Basically that's a
whole new project! :-/

> In any case, if you want to make it happen, I guess you need to
> persuade the admins of it being a worthwhile investment of their time.

Also it's not only installation. There is migration of the whole bugs
(current and closed. We don't want to lose history) to be done, users,
filters (do they even have bug filters in gitlab as powerful as in
bugzilla?), etc.. And probably much more I don't see right now.

> You probably also want to get the buy-in of the main "customers" of the
> new programme which is probably best to get on d-d-l.
>
> Cheers,
>   Tobi
> _______________________________________________
> gnome-infrastructure mailing list
> gnome-infrastructure gnome org
> https://mail.gnome.org/mailman/listinfo/gnome-infrastructure


Jehan

-- 
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot