Things we need to be able to track in a bug: A nomination for fixing in a particular branch An approval for fixing in a particular branch A rejection for fixing in a particular branch That a fix has landed on a particular branch That a fix has been verified on a particular branch The longer term plan is to do something much more elegant with tracking bugs or other mechanisms but keywords will do for now. There are currently three groups which need this information. The groups are firstname.lastname@example.org, email@example.com and firstname.lastname@example.org. Each of these groups will need the nomination approval rejection triad for each of the branches that the group cares about. For email@example.com this is all milestone branches. For firstname.lastname@example.org this is the 0.9.4 branch. For PDT this is the ? (which branch is PDT likely to care about next?). The fixed landed and fix verified keyword states are specific to the branches but not to the groups so one set covers all groups for any given branch. Immediate need is for the addition of embedding (edt) nomination, approval and rejection keywords. We also need keywords for "landed on branch" and "verified on branch" (we're working on multiple branches at the same time so the existing vbranch keyword needs to be replaced with keywords for each branch.) -------------------------------------------------------------------------- This bug tracks these keyword additions. edt0.9.4: use this keyword to nominate embedding bugs for fixing on the 0.9.4 branch. edt0.9.4+: this keyword will replace the edt0.9.4 nomination keyowrd if the bug has been approved by the Netscape embedding delivery team for fixing on the 0.9.4 branch. edt0.9.4-: this keyword will replace the edt0.9.4 nomination keyword if the bug has been rejected by the Netscape embedding delivery team for fixing on the 0.9.4 branch. landed0.9.4: use this keyword when a fix lands on the 0.9.4 branch. landed0.9.6: use this keyword when a fix lands on the 0.9.6 branch. verified0.9.4: use this keyword when a fix has been verified on the 0.9.4 branch. verified0.9.6: use this keyword when a fix has been verified on the 0.9.6 branch. (will consult with drivers before adding these:) mozilla0.9.6+: this keyword will replace the mozilla0.9.6 nomination keyword if the bug has been approved by email@example.com for fixing on the 0.9.6 branch. mozilla0.9.6-: this keyword will replace the mozilla0.9.6 nomination keyword if the bug has been rejected by firstname.lastname@example.org for fixing on the 0.9.6 branch. -------------------------------------------------------------------------- I think this is what we discussed. Please correct any mistakes I've made. Thanks.
I have problems with the following: "That a fix has landed on a particular branch That a fix has been verified on a particular branch" Fixes usually land on a trunk first (when everybody can check-in). We usually protect only branches (but we may need to be ready to do the same for the trunk). Therefore for the embedding and maybe for other non-tip branches we need: landedTrunk (or just landed?): use this keyword when a fix lands on the trunk verifiedTrunk (or just verified?): use this keyword when a fix has been verified on the trunk. I don't think we will need 094 nor 096 counterparts (but you could prove me wrong).
When a fix lands on the trunk the bug's resolution changes to FIXED. When a bug is verified on the trunk the bug's Status changes to VERIFIED. There is no reason for this to change.
edt* keywords created. will add landed, verified and mozilla* keyowords next.
There is at least reason for a process announcement for bugs that land on the trunk. See two conflicting styles for the embedding bugs: (i) comment in status summary "Checked into trunk" http://bugzilla.mozilla.org/show_bug.cgi?id=80784 (ii) resolved as fixed http://bugzilla.mozilla.org/show_bug.cgi?id=98901 We need to [agree and] announce what the right approach is. In the case (i) we need to leave the bugs open, mark them with landedTrunk (and later verifiedTrunk) keyword(s) and finally resolve them FIXED when we are really done with it. To scrub/query the bug system for bugs that still need to be landed on the branch we need to look for open bugs that are of interest to the project (e.g., with topembed keyword or nsbranch+) and look for landedTrunk and/or verifiedTrunk keyword. Query most likely will return few bugs to look at. In the case (ii) we resolve the bug FIXED, and mark the bug with landed0.9.4 (and later verified0.9.4) keyword(s) AFTER it landed/was verified on the branch. To scrub/query the bug system for bugs that still need to be landed on the branch we need to look for FIXED bugs that are of interest to the project (e.g., with topembed keyword or nsbranch+) and look for bugs WITHOUT landed0.9.4 or verified0.9.4 keyword (later WITHOUT every possible landed* or verified* which will have to be explicitly enumerated). Query most likely will return tens to thousands bugs to look at.
Thanks Asa! until we figure out how to represent branches more effectively in bugzilla, I vote for marek's "ii" description (which I believe is what asa is suggesting as well). So, in answer to the questions: -Q: "I fixed it on the trunk but we still need it on the branch; what do I do?" -Ans: "mark the bug fixed, and make sure it's either nominated for the branch (edt0.9.4) or has been approved for the branch (edt0.9.4+)" -Q: "I fixed it on the branch, what do I do?" -Ans: "add the landed keyword (landed0.9.4)"
qa note, i see: edt0.9.4 edt0.9.4+ edt0.9.4- i don't see landed* verified* or mozilla0.9.6[+-]
When a bug fix lands on the trunk (which it should before it lands on any branch) it is marked RESOLVED FIXED (and maybe VERIFIED). Bugs do not stay open after a fix has landed on the trunk.
Thought I'd post this exchange between Asa and I here: Q: What's the process if a bug which has "fixed0.9.x" keyword has to be "reopened" such that the fix did not work on the branch? Do we remove the fixed0.9.x keyword? A: I think so. Then it returns to the "plussed" state and the process starts over.
There are two existing keywords 'vtrunk' and 'vbranch'. The current definitions are related to mn6 branch which is now outdated. Also, I think at times they have been used incorrectly. For instance, the current definition of 'vtrunk' is: 'Resolved bugs with this keyword need to be verified on the trunk' So, basically the keyword is a request for verification on the trunk. I believe sometimes it is being used in the opposite way. We need the functionality of such keywords for application in regards to 0.9.4ec branch v.s trunk builds, whether we use the same names (with updated definitions) or we establish new keywords.
Christine, when a bug is fixed on the branch the developer should be adding the "fixed0.9.4" keyword. QA can query for bugs with this keyword to get the list of bugs that need verification (just like a query for Resolved Fixed). When QA verifies the fix they add the keyword "verified0.9.4". We're basically mirroring the status and resolution in keywords. The vtrunk and vbranch keywords will be going away soon. I need to file another bug to track that.
new branches will reuire new bugs. We've got 0.9.4 and 0.9.9 set for EDT with the full package of nominate, accepted, denied, fixed and verified.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
vrfy full gambit for 0.9.4/0.9.9 I can't remember what 0.9.7 is for :-(
Status: RESOLVED → VERIFIED
Summary: create some more project management keywords → create 0.9.4/0.9.9 edt*, edt*+, edt*-, fixed*, 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.