On Sun, 05 Jan 2014 15:42:48 -0800 Brian Dolbec 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 : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D