Re: Pilot GitLab program
Hey Milan, On Wed, Jun 28, 2017 at 2:16 PM, Milan Crha wrote: > On Wed, 2017-06-28 at 10:15 +0200, Carlos Soriano wrote: > > > 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? > > Hi, > I do not use GitLab, thus I do not know. That's why I'm asking (missing > question mark and actual question, I'm sorry). I understand it as > "possible", thus okay. And it also means no unique numbers for > products. > > It's very time consuming to address questions individually. I would appreciate if you try on the test instance first if you have any wondering (or read our expected workflow https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/GitLabWorkflows where we mention moving issues between products is possible). > > 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. > > It's not exactly negative filtering on bugzilla, it filters for bugs > with: bug_status=UNCONFIRMED & bug_status=NEW & bug_status=ASSIGNED & > bug_status=REOPENED > Ah good point. We could do that without problems, thanks for pointing out. > > > Hope you understand a change without compromises is not possible. > > Sure. As always, it's about the change. Once I get to it, and change my > developed work flow for years, the fallout will not be that drastic as > at the beginning. The thing (for me) is that if I have fine tuned work > flow which I really use for years, every single day, then change it > will not be any fun. Again, for me. Call me an old school, I'm fine > with it :) > I completely understand. The pain of a change will hit all of us in some degree. For me is less severe, but I understand for people doing the same thing for several years is painful. I hope we can mitigate that as much as possible, while keep moving things forward. So far the feedback from other people that was "forced" to use other tools like GitHub etc is that it's just a matter of getting used to it, and that now is fine. Not old school here, you can see this with any change in life. It's just how we are! Cheers, Carlos Soriano > > Bye, > Milan > ___ > 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
Re: Pilot GitLab program
On Wed, 2017-06-28 at 10:15 +0200, Carlos Soriano wrote: > > 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? Hi, I do not use GitLab, thus I do not know. That's why I'm asking (missing question mark and actual question, I'm sorry). I understand it as "possible", thus okay. And it also means no unique numbers for products. > 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. It's not exactly negative filtering on bugzilla, it filters for bugs with: bug_status=UNCONFIRMED & bug_status=NEW & bug_status=ASSIGNED & bug_status=REOPENED > Hope you understand a change without compromises is not possible. Sure. As always, it's about the change. Once I get to it, and change my developed work flow for years, the fallout will not be that drastic as at the beginning. The thing (for me) is that if I have fine tuned work flow which I really use for years, every single day, then change it will not be any fun. Again, for me. Call me an old school, I'm fine with it :) Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pilot GitLab program
Hey Milan, On Wed, Jun 28, 2017 at 8:42 AM, Milan Crha wrote: > 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: > Indeed, that page is for us to summarize, you can add random comments in https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/Comments 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 > do. 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, > Milan Thanks for your feedback Milan! > > > ___ > 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
Re: Pilot GitLab program
Hi, On Wed, 2017-06-28 at 08:42 +0200, Milan Crha wrote: > 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/Commun > > ityInput > > 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? Yes, you can put it anywhere in the commit message. And do note that you don't have to use « Closes #NNN », you can also use « Closes https://./NNN ». Put that on its own line to make it more readable to human, replace « Closes » by « Fixes » (one less letter to type :P ) and you get something very close to the current practice of referencing Bugzilla tickets in commit messages. :) -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
