Re: Pilot GitLab program

Hey Milan,

On Wed, Jun 28, 2017 at 8:42 AM, Milan Crha <mcrha redhat com> wrote:
On Tue, 2017-06-27 at 10:54 +0200, Carlos Soriano wrote:
> We’ve been collecting the feedback on this wiki page:

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:

Indeed, that page is for us to summarize, you can add random comments in or as you did now, by email.

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

How is this missing In GitLab?

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.

Indeed, I forgot to change this in the workflow wiki page. This was pointed out by Florian in the past, and we agreed is a good idea to put the full link.
I just changed it now.

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?

With the change above, you are now in the same situations as before.

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).

No. Negative filtering (idk how to call it properly, but removing from search specific terms) is something I'm interested to bring up to GitLab team. Eventually we will need this for duplicates.

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.

Sounds good.

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

Best thing you can do, try it. That's why we set up the GitLab test instance.

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

Hope you understand a change without compromises is not possible. Our duty here is to minimize the compromises that impact greatly and every day to most of GNOME developers. And this is what we are trying hard to do in our conversations with GitLab team and in our work with the porting tools, wiki docs, bots, etc.

        Thanks and bye,

Thanks for your feedback Milan!

desktop-devel-list mailing list
desktop-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]