Re: [gentoo-portage-dev] Bugzilla workflow
On Tuesday 14 January 2014 21:58:38 Tom Wijsman wrote: On Sun, 05 Jan 2014 15:42:48 -0800 Brian Dolbec wrote: 2) start working on a solution, a) if you have significant progress, but need more time, mark it accordingly, assign it to yourself, leave a comment, etc. Assigning it to oneself is a quite good idea as it allows to easily keep track of the bugs you are working on, otherwise you have to rely on techniques that aren't optimal; which are unfortunate. In the lists of all bugs, that can be obtained by checking out the product and/or categories; this gives a quite clear overview of who is working on what, as well as which bugs are still free. As this is still able to be done, there seems no need to assign the bug to Portage team. i disagree. dev-portage@ get's cc-ed on bugs when they're being kept abreast of developments (like PMS), or someone just wants an opinion/feedback on an issue. so there's no way to differentiate between bugs that are assigned to the portage team and bugs where the portage team's opinion is being requested. i want a query for the former and i just rely on generated bugzilla e-mails for the latter. what's wrong with using the whiteboard ? it's a free text field and you can easily construct a query that produces exactly what you want. just stick in your username in there. 3) commit the fix. Mark it as InVCS, if not already, set status to IN_PROGRESS InVCS becomes redundant; other than that, good. i don't see how it's redundant. there is no other flag that indicates things have been fixed in the git tree and the only reason the bug remains open is that a release has not yet been cut. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] Bugzilla workflow
On Sun, 05 Jan 2014 15:42:48 -0800 Brian Dolbec dol...@gentoo.org wrote: So, a suggested workflow is: I like this workflow the most; however, feedback on it appears to be missing and the document incorporation seems to outright ignore it. Can we please (re)consider and discuss this? 1) check a bug, a) if you can reproduce, then mark it as CONFIRMED Filtering by CONFIRMED bugs if you want to start on a fix right away is very handy to do. b) not enough info, can't reproduce,... mark or comment it accordingly. Definitely, bugs lingering on in UNCONFIRMED for too long is a bad idea; otherwise they would collect over time, not processing bugs in a timely fashion is something we'd like to avoid as to not upset users. 2) start working on a solution, a) if you have significant progress, but need more time, mark it accordingly, assign it to yourself, leave a comment, etc. Assigning it to oneself is a quite good idea as it allows to easily keep track of the bugs you are working on, otherwise you have to rely on techniques that aren't optimal; which are unfortunate. In the lists of all bugs, that can be obtained by checking out the product and/or categories; this gives a quite clear overview of who is working on what, as well as which bugs are still free. As this is still able to be done, there seems no need to assign the bug to Portage team. Leaving a comment is something I'll try to do from now on too. b) If you have a patch but need it tested before committing, upload it there with the request. I suppose URL or attachment suffices, this sounds good. c) Optionally mark it as IN_PRROGRESS for a b above when appropriate. This should be more clear cut; if we want this to be effective, it should be like before which has clear value on the blockers that we use. As it gives a quick overview of what is in master and what is not. 3) commit the fix. Mark it as InVCS, if not already, set status to IN_PROGRESS InVCS becomes redundant; other than that, good. 4) make a release with the patch/fix. Mark the bug RESOLVED, FIXED. Sounds good. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Bugzilla workflow
Here's a new version of the workflow that tries to incorporate all the comments. This should go into the DEVELOPING file once everyone agrees. Bugzilla There always exists a tracker bug, named: [Tracker] sys-apps/portage-next version. This bug is renamed from X.Y.Z to X.Y.Z+1 after a release, until it gets closed when Y changes and a new one is opened. Whenever a commit for a specific bug is made to the git repo, the corresponding bug gets changed in the following ways: * InVCS is added to Keywords * The bug is marked as blocking the tracker for the next version * A comment is added saying: This is fixed in git: url to commit (note that the bug stays open) After a release all open bugs blocking the tracker are closed with the comment This is fixed in version.. For individual open bugs it is encouraged to set UNCONFIRMED, CONFIRMED or IN_PROGESS as appropriate. There are a number of bugs named [TRACKER] * that collect bugs for specific topics. Confirmed bugs should be marked as blocking these tracker bugs if appropriate. It is encouraged to set the alias field for frequently used bugs.
Re: [gentoo-portage-dev] Bugzilla workflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/01/14 23:05, Sebastian Luther wrote: I like this workflow because it makes it easy to see what has been fixed since the last release. The only thing I have no use for, is this InVCS keyword. I do not know what Zac used it for. Does anyone have a use for it? I'm not sure what your confusion is. When a fix is pushed, it is InVCS. The bug is not SOLVED, because it only InVCS, not in a release. Another topic is the bug status for open bugs, i.e. CONFIRMED, UNCONFIRMED, IN_PROGRESS. I've never bothered with changing them and haven't found them useful, but Brian suggested to use IN_PROGRESS at times. What are your thoughts? My interpretation is that CONFIRMED bugs are bugs that a developer is able to reproduce, and IN_PROGRESS bugs are bugs that a developer is presently working on a fix for. CONFIRMED is, in my opinion, very useful. IN_PROGRESS is not that interesting. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLJ2lYACgkQRtClrXBQc7WCUgEApkPtEfm+NbZ6h61++6LmBlUa NXqlny20ZRtEqHFIDWMBAIl0meIaehTKe9Y/ZJZFhViCz/P9YOI0A2eJykPjLNdn =ffkw -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Bugzilla workflow
On Sun, 2014-01-05 at 23:19 +0100, Alexander Berntsen wrote: On 05/01/14 23:05, Sebastian Luther wrote: I like this workflow because it makes it easy to see what has been fixed since the last release. The only thing I have no use for, is this InVCS keyword. I do not know what Zac used it for. Does anyone have a use for it? I'm not sure what your confusion is. When a fix is pushed, it is InVCS. The bug is not SOLVED, because it only InVCS, not in a release. Another topic is the bug status for open bugs, i.e. CONFIRMED, UNCONFIRMED, IN_PROGRESS. I've never bothered with changing them and haven't found them useful, but Brian suggested to use IN_PROGRESS at times. What are your thoughts? My interpretation is that CONFIRMED bugs are bugs that a developer is able to reproduce, and IN_PROGRESS bugs are bugs that a developer is presently working on a fix for. CONFIRMED is, in my opinion, very useful. IN_PROGRESS is not that interesting. Oh, but it does has uses. If you open the tracker bug. The bug numbers listed as blockers. Hover your mouse over the bug number. A small popup window appears and shows the bug summary and status. The keywords are not listed. So, for a bug that has a fix in git for already. If you change the status to IN_PROGRESS, then that status is visible in the popup. Making it easier to not keep revisiting a bug only to discover it is already fixed. Same applies to the bug search page. The status is shown, but not the keywords. I don't know about you, but even though I have a good memory for numbers. It is not that good. They all look alike ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] Bugzilla workflow
On Sunday 05 January 2014 17:05:04 Sebastian Luther wrote: For now I tried to handle bugs like Zac did. That is: There always exists a tracker bug, named: [Tracker] sys-apps/portage-next version. would be nice to start adding an alias field. this way you can do: https://bugs.gentoo.org/show_bug.cgi?id=portage-2.2.8 I like this workflow because it makes it easy to see what has been fixed since the last release. The only thing I have no use for, is this InVCS keyword. I do not know what Zac used it for. Does anyone have a use for it? you can add a bug blocking the release tracker that hasn't yet been fixed in git. the InVCS tag let's people filter between the two states. Another topic is the bug status for open bugs, i.e. CONFIRMED, UNCONFIRMED, IN_PROGRESS. I've never bothered with changing them and haven't found them useful, but Brian suggested to use IN_PROGRESS at times. What are your thoughts? i don't personally care about any of those, but some people find it useful. they all make sense, so it's just a matter of people using them to keep track of things. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] Bugzilla workflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/01/14 23:30, Brian Dolbec wrote: If you open the tracker bug. The bug numbers listed as blockers. Hover your mouse over the bug number. A small popup window appears and shows the bug summary and status. The keywords are not listed. So, for a bug that has a fix in git for already. If you change the status to IN_PROGRESS, then that status is visible in the popup. Making it easier to not keep revisiting a bug only to discover it is already fixed. Same applies to the bug search page. The status is shown, but not the keywords. OK, let's drop InVCS and use IN_PROGRESS to mean fix in git. I don't know about you, but even though I have a good memory for numbers. It is not that good. They all look alike ;) I tend to focus on a small subset of bugs (that I find interesting) at the time, so I had not considered this use case. Thanks. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLJ4pQACgkQRtClrXBQc7UOsQEAtX0uK1qha4ttHD9HDimAnFJy DzxGu8v4t86cTqgYY+4BAKS7DmGSc3Y1M+0voiWTcQCPNTX1j63vZ+m4rvj+p3Kj =V1Bd -END PGP SIGNATURE-
