| 1 |
On Sun, 2014-01-05 at 18:04 -0500, Mike Frysinger wrote: |
| 2 |
> On Sunday 05 January 2014 17:54:12 Alexander Berntsen wrote: |
| 3 |
> > On 05/01/14 23:30, Brian Dolbec wrote: |
| 4 |
> > > If you open the tracker bug. The bug numbers listed as blockers. |
| 5 |
> > > Hover your mouse over the bug number. A small popup window |
| 6 |
> > > appears and shows the bug summary and status. The keywords are not |
| 7 |
> > > listed. So, for a bug that has a fix in git for already. If you |
| 8 |
> > > change the status to IN_PROGRESS, then that status is visible in |
| 9 |
> > > the popup. Making it easier to not keep revisiting a bug only to |
| 10 |
> > > discover it is already fixed. Same applies to the bug search page. |
| 11 |
> > > The status is shown, but not the keywords. |
| 12 |
> > |
| 13 |
> > OK, let's drop InVCS and use IN_PROGRESS to mean "fix in git". |
| 14 |
> |
| 15 |
> those aren't the same thing |
| 16 |
> -mike |
| 17 |
|
| 18 |
IN_PROGRESS essentially means it is or has been looked after already. |
| 19 |
Adding the InVCS keyword further indicates the fix is applied somewhere |
| 20 |
already. |
| 21 |
|
| 22 |
So, a suggested workflow is: |
| 23 |
|
| 24 |
1) check a bug, |
| 25 |
a) if you can reproduce, then mark it as CONFIRMED |
| 26 |
b) not enough info, can't reproduce,... mark or comment it |
| 27 |
accordingly. |
| 28 |
2) start working on a solution, |
| 29 |
a) if you have significant progress, but need more time, mark it |
| 30 |
accordingly, assign it to yourself, leave a comment, etc. |
| 31 |
b) If you have a patch but need |
| 32 |
it tested before committing, upload it there with the request. |
| 33 |
c) Optionally mark it as IN_PRROGRESS for a & b above when |
| 34 |
appropriate. |
| 35 |
3) commit the fix. Mark it as InVCS, if not already, set status to |
| 36 |
IN_PROGRESS |
| 37 |
4) make a release with the patch/fix. Mark the bug RESOLVED, FIXED. |
Archives