All users were logged out of Bugzilla on October 13th, 2018
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.
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.
Summary: Remove vbranch and vtrunk keywords. → Remove vbranch and vtrunk keywords.
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?
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?]?
There will only be fixed, not landed.
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.
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?
lchiang, your examples are correct.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.