akeybl
unread,Sep 13, 2012, 1:13:27 AM9/13/12You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to ehsan....@gmail.com, justin...@gmail.com, dev-pl...@lists.mozilla.org, rya...@gmail.com
If we do this, we should all agree that when status-firefox(n) is set to fixed, the bug is resolved, and status-firefox(n+1) is unset, it's implied that Firefox(n+1) is fixed as well. That's the one thing that the target milestone implies but the status flags do not currently. Might be obvious, but wanted to get it down nonetheless.
-AlexEhsan Akhgari <
ehsan....@gmail.com> wrote:On 12-09-12 4:34 PM, Justin Lebar wrote:
>> If you're talking about setting the target milestone when landing on
>> inbound, that requirement was already dropped a couple months ago. The tool
>> we use for resolving bugs after merging to m-c handles setting it.
>
> No, I was suggesting that the target milestone should simply not be
> set, by the automated tool or otherwise, because it would duplicate
> the status-firefox-N status.
That makes a lot of sense. In fact, I'd go one step further and say
that we should probably hide that field for Firefox/Toolkit/Core at least.
> That said, it looks like we delete / hide the status-firefox-N flags
> once version N is obsolete. So that's a good reason to keep the
> target milestone around...
I'm pretty sure we don't delete them, we just hide them. But I also
think that is something that we can change, given that in the long past
we used to preserve the flags that were now obsolete, just made them
non-editable.
Who wants to file the BMO bug? :-)
Cheers,
Ehsan