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.
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. > >> * 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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
