107788 - Remove vbranch and vtrunk keywords.

Status: VERIFIED FIXED

(bugzilla.mozilla.org :: Administration, task)

Description

[Asa Dotzler [:asa]]

I'll be making verified<branch> keywords for each interesting branch. This new
keyword will be a flag the the bug _has_ _been_ verified on the branch. To
decide if a bug _needs_ verification on the branch look for the new
'landed<branch>' keyword. 

The current active branch is 0.9.4.  QA can query for keyword 'landed0.9.4' for
a list of bugs that need to be verified on the 0.9.4 branch.  When a
verification is complete QA will add the 'verified0.9.4' keyword to the bug.
We're basically implementing a secong set of Resolutions (Fixed and Verified)
using keywords. The previous vbranch and vtrunk keywords were confusing. This
should make things a bit easier. 

More (in case it's not clear). The life cycle of a bug which is worked on for
the trunk and the 0.9.4 branch looks something like this:

A bug is reported.  Someone adds the branch nomination keyword, edt0.9.4,
identifying the bug as a problem that should be fixed on the trunk and on the
0.9.4 branch. 
A developer lands the fix on the trunk and Resolves the bug as Fixed using the
normal Bugzilla fields. This initiates the Verification process. QA sees that
the bug has been Resolved as Fixed and completes its Verification using the
normal Bugzilla fields. Project management has confidence the checkin actually
fixed the problem.
Project management adds the branch acceptance keyword edt0.9.4+ which signals
the developer to land the fix on the 0.9.4 branch. When the developer lands the
fix on the 0.9.4 branch he will add the 'landed0.9.4' keyword, resolving it as
fixed on the branch. 
QA sees the 'landed0.9.4' keyword and completes it's Verification on the 0.9.4
branch, adding the 'verified0.9.4' keyword.  
Now the bug has flags for Fixed and Verified on both the branch and the trunk.
The bug will have the Status Verified, the Resolution Fixed, and the keywords
'landed0.9.4' and 'verified0.9.4'.

I hope this makes more sense than the current system. I know it sucks to be
changing this all the time and I expect it to change one more time when Bugzilla
can be made to understand multiple 'views' of a bug. Until then I think that
this system will be more consistent and hopefully more effective. 

I'll wait a day or so before making this change and I'll record the bugs that
had vbranch and vtrunk keywords here so that the information isn't lost.

Comment 1

[lchiang]

Asa - thanks.  I'm going to send this bug off to QA for some feedback and ask
folks to comment on any concerns in the bug.

Comment 2

[lchiang]

1.  When a bug gets verified on the branch and marked "verified<branch>" (with
milestone replacing the <branch> text), does the "landed<branch>" keyword remain?

2.  During this entire time, the bug remains in RESOLVED or VERIFIED state?

Comment 3

[sairuh (rarely reading bugmail)]

are we going to use 'landed<branch#>' or 'fixed<branch#>' to denote fixed bugs?
or, are those going to be separate kw's with distinct meanings [of yes, what's
the difference?]?

Comment 4

[lchiang]

There will only be fixed, not landed.   

Comment 5

[Asa Dotzler [:asa]]

lchiang, 

1. the fixed0.9.4 keyword should probably stay. no need to throw away that info
(and I think it's easier if we tell people all they have to do is add a keyword.
for small groups like the pdt doing keyword replacement is easy but when we move
to the larger groups of developers and qa then I think it's probably best to
keep it simple.)
2. yes. during this entire time the bug remains in the resolved or verified state.

basically we're creating another status and resolution with keywords. 

sorry about the 'landed' minor fiasco. landed was a bad choice I made for the
keyword. we will use 'fixed' and not landed.  

Comment 6

[lchiang]

This sounds good to me.  

For bugs which we want into multiple branches, we use keywords (fixed<branch>
and verified<branch>) to identify the fixed/verfied states.   We continue to use
the main resolution fields to track trunk landings.

Some scenarios:  This is assuming that the proper keywords are on the bug
already to track that they are wanted on some branch.

1.  There is a bug we want for both 0.9.x branch and trunk.   The bug gets fixed
into the branch first.  The bug gets marked w/keyword fixed0.9.x (where x is
some number for the branch).  If QA verifies, keyword verified0.9.x gets added.
 Bug's main resolution remains ASSIGNED.   Fix goes into the trunk.  Bug gets
marked FIXED (and then gets VERIFIED) as necessary.

2.  There is a bug we want for both 0.9.x branch and trunk.  The bug gets fixed
into the trunk first.  The bug gets marked FIXED (and then VERIFIED) (under the
main fields).   Fix goes into the branch.  The bug gets marked w/keyword
fixed0.9.x (and verified0.9.x as necessary).

Right?

Comment 7

[Asa Dotzler [:asa]]

lchiang, your examples are correct. 

Comment 8

[Asa Dotzler [:asa]]

all vbranch keywords at time of posting.
http://bugzilla.mozilla.org/buglist.cgi?bug_id=,52667,53504,55306,55193,55461,36381,56823,38029,53974,57449,55600,54789,55838,73390,86894,88838,87535,87991,86957,76722,81290,89628,40072,90733,90215,83433,89181,84264,87047,45892,54860,86966,90505,90524,90624,67329,88087,95404,80789,94038,86984,90392,100700,88678,108751,85451,73141,36796,110242,81203,129410,121336

all vtrunk keywords at time of posting
http://bugzilla.mozilla.org/buglist.cgi?bug_id=,39703,55277,54585,56599,46134,55405,56529,57361,57028,52856,54874,59102,57733,51446,9217,31964,40617,57002,34924,56284,55179,55184,46888,57139,27790,58323,54468,54841,55424,20743,53580,56159,1046,12078,36868,55352,54051,45567,57054,55983,48036,57850,51939,56390,59460,57070,54501,58021,55993,56459,50584,57165,54604,54545,54091,13871,54381,56009,58774,37886,82461,83980,83977,80512,79205,84070,87911,87202,81738,79487,68985,79584,87396,83107,86673,89189,48403,85984,87961,58428,89345,74139,52564,88955,85813,90073,90371,87508,89139,65251,84051,29756,48887,88343,32801,57495,86133,91140,87872,91438,58037,91717,83753,52276,87793,84264,87047,57034,86197,87586,44582,65209,83763,86265,91710,87720,86199,87028,43248,91043,54782,83381,90159,82761,60514,68993,87167,83143,38123,76848,85054,70517,85237,87110,88277,87346,81288,58012,86742,56136,89249,79551,98810,72152,76603,97533,98261,98597,100106,53349,92348,93857,92447,97226,99056,66772,77078,94193,92322,88575,96413,70034,95489,96017,85701,96362,78021,99569,59211,99271,30988,94341,95840,98292,57673,98270,96228,50423,101674,100568,99948,83425,83639,75946,91597,89698,56002,88155,96153,103181,77603,99102,102705,103410,100668,104181,101936,100168,101795,94219,79974,83570,103031,102002,101608,84234,105896,102376,59871,99920,22526,102545,97997,27327,56010,88052,99491,97541,94319,55731,58584,103539,88315,89950,97549,78828,91744,98187,56245,95584,100645,57902,96979,52368,100727,90151,90196,101122,107973,98262,78480,10434,26178,29033,59604,54165,57195,85632,101832,99364,76715,38468,57181,96015,92248,78428,80802,98391,97362,58753,74383,104692,96056,93371,80220,103897,97687

Comment 9

[timeless]

vrfy fixed