> 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.
One correction - these flags can still be modified (if previously set) but can't be set for the first time once they've been removed. > Target Milestone = Firefox 23 & Resolution = FIXED > > or > > status-firefox23 = fixed, verified, verified disabled Add in disabled for the status and a resolution of verified, and this is correct. > 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. The only 100% sure fire way of knowing is code inspection. Even programmatically trying to read through commit logs isn't enough information to build a fix list given backouts. We need to be good about following process. -Alex On Apr 10, 2013, at 3:14 PM, Jason Smith <jsm...@mozilla.com> wrote: > 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
