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