On Sun, 2014-01-05 at 18:04 -0500, Mike Frysinger wrote: > On Sunday 05 January 2014 17:54:12 Alexander Berntsen wrote: > > 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". > > those aren't the same thing > -mike
IN_PROGRESS essentially means it is or has been looked after already.
Adding the InVCS keyword further indicates the fix is applied somewhere
already.
So, a suggested workflow is:
1) check a bug,
a) if you can reproduce, then mark it as CONFIRMED
b) not enough info, can't reproduce,... mark or comment it
accordingly.
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.
b) If you have a patch but need
it tested before committing, upload it there with the request.
c) Optionally mark it as IN_PRROGRESS for a & b above when
appropriate.
3) commit the fix. Mark it as InVCS, if not already, set status to
IN_PROGRESS
4) make a release with the patch/fix. Mark the bug RESOLVED, FIXED.
signature.asc
Description: This is a digitally signed message part
