107488 - create 0.9.4/0.9.9 edt*, edt*+, edt*-, fixed*, verified*

Status: VERIFIED FIXED

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

Description

[Asa Dotzler [:asa]]

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
[e-mail], [e-mail] and [e-mail]. Each of these groups
will need the nomination approval rejection triad for each of the branches that
the group cares about. For drivers@m.o this is all milestone branches. For
edt@n.c 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 [e-mail] 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 [e-mail] for fixing on the 0.9.6 branch.

--------------------------------------------------------------------------

I think this is what we discussed. Please correct any mistakes I've made. Thanks.

Comment 1

[Marek Z. Jeziorek]

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).

Comment 2

[Asa Dotzler [:asa]]

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. 

Comment 3

[Asa Dotzler [:asa]]

edt* keywords created. will add landed, verified and mozilla* keyowords next.

Comment 4

[Marek Z. Jeziorek]

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. 

Comment 5

[Judson Valeski]

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)"

Comment 6

[timeless]

qa note, i see: edt0.9.4 edt0.9.4+ edt0.9.4-
i don't see landed* verified* or mozilla0.9.6[+-]

Comment 7

[Asa Dotzler [:asa]]

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. 

Comment 8

[lchiang]

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.

Comment 9

[Christine Hoffman]

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. 

Comment 10

[Asa Dotzler [:asa]]

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. 

Comment 11

[Asa Dotzler [:asa]]

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. 

Comment 12

[timeless]

vrfy full gambit for 0.9.4/0.9.9
I can't remember what 0.9.7 is for :-(