Comments inline.
Sincerely,
Jason Smith
Desktop QA Engineer
Mozilla Corporation
https://quality.mozilla.com
On 4/10/2013 2:19 PM, Justin Lebar wrote:
Right now the status and tracking flags for a version get hidden when
that version becomes old. If we switched away from using
target-milestone, we'd need to prevent this from happening.
Ah, good point. Didn't think of that initially. That would actually
argue in favor of target milestone being the permanent entity and the
status flags only existing within the release --> beta --> aurora -->
nightly timeframe.
On Wed, Apr 10, 2013 at 4:53 PM, Alex Keybl <ake...@mozilla.com> wrote:
* The need for a particular team to track the concept of "We would
like to get this fixed in this Firefox release." Some teams I've
worked with have considered using the target milestone field here,
but that collides with the trunk management definition, which often
causes contention during the landing or post landing process.
We may want to go into more detail here and see if we can change the trunk
management details in such a way that teams own the target milestone until the
bug is resolved/fixed.
I think that sounds reasonable. We could grant control of the flag for
planning purposes until the patch heads to land. When it lands, the
patch reflects the actual milestone the patch lands in. So the before
and after effect I think achieves both needs here for planning and tree
management.
* The need to be able to query the status-firefox flags to determine
when a patch lands on a per branch basis even if has landed on
trunk. This helps for those tracking fixes to use one universal flag
to query on to determine such things such as:
This does add one extra step, since the person querying needs to include target
milestone and bug resolution in their query. I'd like to hear if this has been
a major pain point for others before reacting.
Followup question on this - the right way to query generally then for
all bugs fixed in a Firefox release? This for say, Firefox 23?
Target Milestone = Firefox 23 & Resolution = FIXED
or
status-firefox23 = fixed, verified, verified disabled
The one challenge I've had is that target milestone however isn't always
set on landing, so there's always risk we could have bugs fall through
the cracks if the target milestone field isn't set.
Knowing this, why not consider just using the status-flags purely to track
landings and let the team determine how to use target milestone? Also, why not
set the status-flag in general for the appropriate Firefox release when a patch
lands on trunk?
The difference between version-specific status flags (fixed) and target
milestone (along with resolved/fixed) is subtle. Status flags being set to
fixed mean this bug has been fixed in this particular version of Firefox. The
combination of a target milestone and resolved/fixed means that a bug is fixed
in all Firefox versions after the one specified. That may prove a little
difficult to untangle.
-Alex
On Apr 10, 2013, at 1:38 PM, Jason Smith <jsm...@mozilla.com> wrote:
Hi Everyone,
Right now, when a landing occurs, my understanding is that we're typically
setting the target milestone field to what Firefox release the code lands on if
it lands on trunk. If a patch is uplifted, then the status flag is set
appropriately for the target Firefox release.
However, after working with three distinct teams, talking with Ed, and
analyzing status flag usage, I have seen these contention points dependent on a
team's method for tracking that might happen:
* The need for a particular team to track the concept of "We would
like to get this fixed in this Firefox release." Some teams I've
worked with have considered using the target milestone field here,
but that collides with the trunk management definition, which often
causes contention during the landing or post landing process.
* The need to be able to query the status-firefox flags to determine
when a patch lands on a per branch basis even if has landed on
trunk. This helps for those tracking fixes to use one universal flag
to query on to determine such things such as:
o What bugs that are features are worth verifying on X branch?
o What bugs that defects are worth verifying on X branch?
Knowing this, why not consider just using the status-flags purely to track
landings and let the team determine how to use target milestone? Also, why not
set the status-flag in general for the appropriate Firefox release when a patch
lands on trunk?
--
Sincerely,
Jason Smith
Desktop QA Engineer
Mozilla Corporation
https://quality.mozilla.com
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
