Needless to say the first interested in GitLab issues working well are themselves.
Said that, over these 3 months of testing, what I saw is that every single concern or proposal I though GitLab Issues could manage better was either implemented or in the works. Their developing pace is actually quite impressive. So I expect more polishing in this part.
-------- Original Message --------
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 16, 2017 4:15 PM
UTC Time: May 16, 2017 2:15 PM
From: tristan vanberkom codethink co uk
To: Allan Day <aday gnome org>, desktop-devel-list <desktop-devel-list gnome org>
On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> [Written on behalf of Alberto Ruiz, Carlos Soriano, Andrea Veri,
> Emmanuele Bassi and myself.]
Hi !
I'd first like to say that I would love it that we embrace gitlab and
run our own gitlab instance to manage GNOME's gits.
There are some great features we can leverage, the ones I'm most
interested in are:
o Pre merge CI pipelines manageable on a per-project basis, this
is really great
o Merge requests (need I say more ?)
o Pages are also a great feature, if we could have that to allow
projects to setup their own pages deployments from their
.gitlab-ci.yml, that would be a bonus.
However I'm not sure if that would be too much of a radical change
from the experience we have now with developer.gnome.org and the
wiki.
I don't share your optimism about gitlab bug tracking, nor do I share
in the mentioned frustration with bugzilla. However if I need to trade
what I believe to be a far superior bug tracking infrastructure for a
weaker one provided by gitlab, the other benefits far outweigh the
loss.
Regarding bug tracking, these are some things I think are important,
some of which gitlab already handles fine, others not so much:
o For a relatively "stable" software, I want to keep hundreds of
bugs open at all times, and I want to ideally view them and sort
them, and not have to click through this annoying "pagination"
A bug tracker holds a _lot_ of importance to me in how I like
to manage and document the development of a project, arguably
as much as the source itself; even if an enhancement requests
lays dormant in bugzilla for years, It's always great to have
a full documentation of what you could potentially be doing
better.
o Dependencies, I like that with bugzilla we can make one bug
depend on another, with this we achieve interesting things,
like graphing out the dependencies which lead to a symbolic
milestone.
Yes, I can track milestones on a wiki page or with another
moving part, but then I tend to lose posterity; documenting
as much as possible in your bug tracker helps you to track
the whole project history in one place.
o Real attachments, and a good view of them if possible with
syntax highlighting is great.
I dont like to accept bug reports which contain links out to
external resources if and when at all possible, this makes it
difficult to have good posterity.
If I want to go back in time and remember why this bug was
reproducing last year, I need to have a real attachment (for
example a glade file) and be sure that I'm not stuck with a
link to a resource which may have changed since last year (i.e.
a link to someone's git branch) or disappeared altogether.
o Good email notifications, and hopefully some granularity on
what events I want to listen and be notified for.
Again, gitlab does *some* of this stuff well, but I feel that it's just
good enough for the typically small jquery plugin like projects that
you tend to find hosted on github.
I could not imagine what it might be like to track all the bugs of the
linux kernel, GTK+ bug history, or mozilla, any serious project with
gitlab, the throughput seems to be much too high, while the main
benefits I can see are:
o Automatic integration with the rest of gitlab for free (nice
to have merge requests notify the issues automatically without
having to reference in bug comments, etc). Of course this also
means you have one account for both your git and your bug tracking.
o A bootstrapy JS user interface instead of a more old fashioned UI
(I dont think this is a reasonable argument to trade away a
powerful bug tracker for this alone, though).
All of that said, I am already using gitlab's bug tracking (somewhat
begrudgingly) and with the small bug history I've accumulated so far it
does not seem to be a problem, and as I said above:
If I have to trade in bugzilla in order to win the rest of the
features we get with gitlab, then so be it, sold !
I'm sure you have all thought about much of this already, and thanks a
lot for your hard work !
Best,
-Tristan
> Dear community,
>
> Over the years, many of us have become increasingly frustrated about
> the state of our development infrastructure, Bugzilla in particular.
> Pretty much everyone we’ve spoken to doesn’t like it, and it’s not
> hard to see why: it is littered with usability issues, code review is
> a pain, and it is light-years behind more modern development
> platforms.
>
> In the past, there haven’t been many other options, but we’re now in
> the fortunate position of having viable alternatives and the sysadmin
> resources to set one of them up and maintain it.
>
> In recent months we have got together to examine the possibilities
> for GNOME’s development infrastructure. We’ve spent a lot of time on
> this, because we want the community to have faith in our conclusions.
> If you are interested in this, you can read our research on the wiki
> [1].
>
> The outcome of this evaluation process is that we are recommending
> that GNOME sets up its own GitLab instance, as a replacement for
> Bugzilla and cgit.
>
> We are confident that GitLab is a good choice for GNOME, and we can’t
> wait for GNOME to modernise our developer experience with it. It will
> provide us with vastly more effective tools, an easier landing for
> newcomers, and lots of opportunities to improve the way that we work.
> We're ready to start working on the migration.
>
> Please bear in mind that this is just a recommendation! We are not
> claiming to have complete knowledge and we would like to hear
> questions and comments. At the same time, we do ask that members of
> the community approach this proposal with an open mind: please read
> the wiki pages and try to resist making assumptions about GitLab
> without familiarising yourself with it.
>
> Yours,
>
> Allan Day
>
>
> [1] https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
