| 1 |
On Sun, 05 Jan 2014 15:42:48 -0800 |
| 2 |
Brian Dolbec <dolsen@g.o> wrote: |
| 3 |
|
| 4 |
> So, a suggested workflow is: |
| 5 |
|
| 6 |
I like this workflow the most; however, feedback on it appears to be |
| 7 |
missing and the document incorporation seems to outright ignore it. |
| 8 |
|
| 9 |
Can we please (re)consider and discuss this? |
| 10 |
|
| 11 |
> 1) check a bug, |
| 12 |
> a) if you can reproduce, then mark it as CONFIRMED |
| 13 |
|
| 14 |
Filtering by CONFIRMED bugs if you want to start on a fix right away is |
| 15 |
very handy to do. |
| 16 |
|
| 17 |
> b) not enough info, can't reproduce,... mark or comment it |
| 18 |
> accordingly. |
| 19 |
|
| 20 |
Definitely, bugs lingering on in UNCONFIRMED for too long is a bad idea; |
| 21 |
otherwise they would collect over time, not processing bugs in a timely |
| 22 |
fashion is something we'd like to avoid as to not upset users. |
| 23 |
|
| 24 |
> 2) start working on a solution, |
| 25 |
> a) if you have significant progress, but need more time, mark it |
| 26 |
> accordingly, assign it to yourself, leave a comment, etc. |
| 27 |
|
| 28 |
Assigning it to oneself is a quite good idea as it allows to easily keep |
| 29 |
track of the bugs you are working on, otherwise you have to rely on |
| 30 |
techniques that aren't optimal; which are unfortunate. |
| 31 |
|
| 32 |
In the lists of all bugs, that can be obtained by checking out the |
| 33 |
product and/or categories; this gives a quite clear overview of who is |
| 34 |
working on what, as well as which bugs are still free. As this is still |
| 35 |
able to be done, there seems no need to assign the bug to Portage team. |
| 36 |
|
| 37 |
Leaving a comment is something I'll try to do from now on too. |
| 38 |
|
| 39 |
> b) If you have a patch but need |
| 40 |
> it tested before committing, upload it there with the request. |
| 41 |
|
| 42 |
I suppose URL or attachment suffices, this sounds good. |
| 43 |
|
| 44 |
> c) Optionally mark it as IN_PRROGRESS for a & b above when |
| 45 |
> appropriate. |
| 46 |
|
| 47 |
This should be more clear cut; if we want this to be effective, it |
| 48 |
should be like before which has clear value on the blockers that we |
| 49 |
use. As it gives a quick overview of what is in master and what is not. |
| 50 |
|
| 51 |
> 3) commit the fix. Mark it as InVCS, if not already, set status to |
| 52 |
> IN_PROGRESS |
| 53 |
|
| 54 |
InVCS becomes redundant; other than that, good. |
| 55 |
|
| 56 |
> 4) make a release with the patch/fix. Mark the bug RESOLVED, FIXED. |
| 57 |
|
| 58 |
Sounds good. |
| 59 |
|
| 60 |
-- |
| 61 |
With kind regards, |
| 62 |
|
| 63 |
Tom Wijsman (TomWij) |
| 64 |
Gentoo Developer |
| 65 |
|
| 66 |
E-mail address : TomWij@g.o |
| 67 |
GPG Public Key : 6D34E57D |
| 68 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |
Archives