Re: Pilot GitLab program

[Milan Crha <mcrha redhat com>]

On Tue, 2017-06-27 at 10:54 +0200, Carlos Soriano wrote:
> We’ve been collecting the feedback on this wiki page:
> https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/CommunityInput

        Hi,
can I add some things I'm missing there? It seems that it's better if
you manage the Wiki page yourself, thus not any "garbage" gets into it,
thus I'd rather write it here:

a) I often move bugs between products, aka user files it for product A,
   but the issue (and actual commit) is in product B, thus it's moved,
   by ~3 clicks
b) some bugs require changes in multiple modules. I reference the same
   bug in all the commits, the same as the bug references all those
   commits, thus it's clear about the changes. Would it be possible
   too, or the issue numbering is unique per product? Unique numbering
   might be a problem, from my point of view.
c) I generate NEWS file from `git log`, which is also the reason why
   commit messages are made the way they are. It saves plenty of time.
   With the "closes #NNN", will it still be possible? Where is the
   "closes #NNN" meant to be, anywhere in the commit message?
d) can be need-info issues hidden in searches? I suppose so, but I do
   not know it. Having free-form labels and trying to type all of them
   into a search term doesn't sound like the way to go (the Wiki page
   suggests to use a need-info label; by the way, I would not rename
   it to "missing info", when the need-info term is widely used and
   already understood by the (not only GNOME) community).

My current use case of bugzilla consists (apart of other things) in one
tab opened with a search for "newly" (since some date) filled bug
reports for products I take care of. Bugs in need-info state are not
interesting, because of awaiting information. When the information is
received I'm notified by mail, thus I do not need to see such bugs in
the list. I refresh the page several times per week to see and
eventually comment on the newly filled bug reports, basically because I
expect that the reporter will be more willing to respond on new bugs,
than on years-old bug reports.

I hope my work flow with bugzilla is not too awkward. I'm not sure
whether I'd be able to do all the above things easily with GitLab issue
tracker. I noticed that some devels do not like bugzilla, but for me
personally it works perfectly fine. The things I want from it can be
easily accomplished with minimal effort (or maybe I'm just used to it
after all those years that it is minimal effort for me) and it is
powerful when it comes to searching. I do not want oversimplified
interface, I want an interface which allows me to do what *I* want to
do.
        Thanks and bye,
        Milan