info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Proposal for new status-firefoxN flag, 'disabled'
30 views
Skip to first unread message
Alex Keybl
Apr 30, 2012, 8:23:55 PM4/30/12
to mozilla.dev.planning >> mozilla.dev.planning group
We use status flags to ensure that everybody understands which FF versions have a bug resolved, and which do not. It's become clear that we can't always properly track the state of a feature in the original bug, since there's no easy way to determine if the fix is enabled, or implemented and disabled. We many times file a separate bug tracking the enabled/disabled state of a new feature instead, obfuscating a feature's true state across versions. Currently we have the following status states:
* 'unaffected' - this version of Firefox is unaffected by the bug
* 'affected' - this version of Firefox is affected by the bug, and has not yet been fixed
* 'wontfix' - this version of Firefox is affected by the bug, but will not receive a fix
* 'fixed' - engineering believes this version of Firefox is unaffected by the bug now that we've landed a patch (if enabled)
* 'verified' - QA has verified this version of Firefox is unaffected by the bug now that we've landed a patch
I'm proposing a change and a couple of new additions to the status flag:
* add the 'disabled' status flag to denote when code change has been taken but is disabled (through a default preference or otherwise)
** 'fixed' would then mean implemented&enabled instead of just implemented
* change 'verified' -> 'verified fixed' so that QA can verify when a feature/fix is implemented and enabled
* add 'verified disabled' so that QA can verify when a feature/fix is implemented but disabled, confirming that there haven't been any functional changes in the user experience
The end goal is to be able to look at the main feature bug and immediately know its full status across releases. I'll wait for feedback here before filing a bug to cover a bugzilla change. Thanks!
-Alex
* 'unaffected' - this version of Firefox is unaffected by the bug
* 'affected' - this version of Firefox is affected by the bug, and has not yet been fixed
* 'wontfix' - this version of Firefox is affected by the bug, but will not receive a fix
* 'fixed' - engineering believes this version of Firefox is unaffected by the bug now that we've landed a patch (if enabled)
* 'verified' - QA has verified this version of Firefox is unaffected by the bug now that we've landed a patch
I'm proposing a change and a couple of new additions to the status flag:
* add the 'disabled' status flag to denote when code change has been taken but is disabled (through a default preference or otherwise)
** 'fixed' would then mean implemented&enabled instead of just implemented
* change 'verified' -> 'verified fixed' so that QA can verify when a feature/fix is implemented and enabled
* add 'verified disabled' so that QA can verify when a feature/fix is implemented but disabled, confirming that there haven't been any functional changes in the user experience
The end goal is to be able to look at the main feature bug and immediately know its full status across releases. I'll wait for feedback here before filing a bug to cover a bugzilla change. Thanks!
-Alex
Justin Wood (Callek)
May 1, 2012, 1:29:49 AM5/1/12
to Alex Keybl
I am indifferent on this proposal as a whole, but I would like to
ask/suggest that SeaMonkey flags follow the same scheme...
Basically "whatever bug you file to change Firefox's flag, if you do,
please mention the SeaMonkey flags along with it".
Thank You,
--
~Justin Wood (Callek)
ask/suggest that SeaMonkey flags follow the same scheme...
Basically "whatever bug you file to change Firefox's flag, if you do,
please mention the SeaMonkey flags along with it".
Thank You,
--
~Justin Wood (Callek)
Jonas Sicking
May 1, 2012, 1:50:09 AM5/1/12
to Alex Keybl, mozilla.dev.planning >> mozilla.dev.planning group
This sounds great to me!
Less confusion about when something got fixed is a big win.
/ Jonas
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Less confusion about when something got fixed is a big win.
/ Jonas
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Justin Dolske
May 1, 2012, 8:09:51 PM5/1/12
to
On 4/30/12 5:23 PM, Alex Keybl wrote:
> I'm proposing a change and a couple of new additions to the status flag:
>
> * add the 'disabled' status flag to denote when code change has been taken but is disabled (through a default preference or otherwise)
> ** 'fixed' would then mean implemented&enabled instead of just implemented
If the code is backed out (eg because it wasn't practical to control
> I'm proposing a change and a couple of new additions to the status flag:
>
> * add the 'disabled' status flag to denote when code change has been taken but is disabled (through a default preference or otherwise)
> ** 'fixed' would then mean implemented&enabled instead of just implemented
with a pref), would it be "unaffected", or "disabled"?
> * change 'verified' -> 'verified fixed' so that QA can verify when a feature/fix is implemented and enabled
> * add 'verified disabled' so that QA can verify when a feature/fix is implemented but disabled, confirming that there haven't been any functional changes in the user experience
just reflecting current practice it's fine.
Justin
Alex Keybl
May 1, 2012, 8:45:42 PM5/1/12
to Justin Dolske, dev-pl...@lists.mozilla.org
Hi Justin,
> If the code is backed out (eg because it wasn't practical to control with a pref), would it be "unaffected", or "disabled"?
If code is backed out, the associated version status would be marked as "unaffected" or cleared entirely from the original feature bug.
> I'm not sure if bug verification really adds much value, but if this is just reflecting current practice it's fine.
QA tries to verify the state of all bugs fixed on aurora/beta before release. I'd like them to be able to confirm that status without making it difficult for us to understand if a fix is enabled or disabled.
-Alex
> If the code is backed out (eg because it wasn't practical to control with a pref), would it be "unaffected", or "disabled"?
> I'm not sure if bug verification really adds much value, but if this is just reflecting current practice it's fine.
-Alex
Dao
May 2, 2012, 5:39:13 AM5/2/12
to
On 02.05.2012 02:45, Alex Keybl wrote:
> Hi Justin,
>
>> If the code is backed out (eg because it wasn't practical to control with a pref), would it be "unaffected", or "disabled"?
>
> If code is backed out, the associated version status would be marked as "unaffected" or cleared entirely from the original feature bug.
Doesn't "wontfix" make more sense than "unaffected", especially when
> Hi Justin,
>
>> If the code is backed out (eg because it wasn't practical to control with a pref), would it be "unaffected", or "disabled"?
>
> If code is backed out, the associated version status would be marked as "unaffected" or cleared entirely from the original feature bug.
referring to actual bugs rather than new features?
Alex Keybl
May 2, 2012, 1:06:55 PM5/2/12
to Dao, dev-pl...@lists.mozilla.org
> Doesn't "wontfix" make more sense than "unaffected", especially when referring to actual bugs rather than new features?
The disabled status will not make sense for bug fixes a majority of the time, it's mostly meant to features. Justin's example of backing out code seems more applicable to a feature bug, in which case 'wontfix'ing or clearing status would both mean that that version does not have any related code.
If backing out a bug fix as opposed to a new feature, 'affected' would be the appropriate status until we've explicitly decided we won't take another stab at fixing the problem in that version, in which case 'wontfix' would be correct.
-Alex
Alex Keybl
May 15, 2012, 8:08:46 PM5/15/12
to mozilla.dev.planning >> mozilla.dev.planning group
We've filed https://bugzilla.mozilla.org/show_bug.cgi?id=755582 to cover this proposal. You can expect to see 'disabled' and 'verified disabled' status flags soon.
-Alex
On Apr 30, 2012, at 5:23 PM, Alex Keybl wrote:
> We use status flags to ensure that everybody understands which FF versions have a bug resolved, and which do not. It's become clear that we can't always properly track the state of a feature in the original bug, since there's no easy way to determine if the fix is enabled, or implemented and disabled. We many times file a separate bug tracking the enabled/disabled state of a new feature instead, obfuscating a feature's true state across versions. Currently we have the following status states:
>
> * 'unaffected' - this version of Firefox is unaffected by the bug
> * 'affected' - this version of Firefox is affected by the bug, and has not yet been fixed
> * 'wontfix' - this version of Firefox is affected by the bug, but will not receive a fix
> * 'fixed' - engineering believes this version of Firefox is unaffected by the bug now that we've landed a patch (if enabled)
> * 'verified' - QA has verified this version of Firefox is unaffected by the bug now that we've landed a patch
>
-Alex
On Apr 30, 2012, at 5:23 PM, Alex Keybl wrote:
> We use status flags to ensure that everybody understands which FF versions have a bug resolved, and which do not. It's become clear that we can't always properly track the state of a feature in the original bug, since there's no easy way to determine if the fix is enabled, or implemented and disabled. We many times file a separate bug tracking the enabled/disabled state of a new feature instead, obfuscating a feature's true state across versions. Currently we have the following status states:
>
> * 'unaffected' - this version of Firefox is unaffected by the bug
> * 'affected' - this version of Firefox is affected by the bug, and has not yet been fixed
> * 'wontfix' - this version of Firefox is affected by the bug, but will not receive a fix
> * 'fixed' - engineering believes this version of Firefox is unaffected by the bug now that we've landed a patch (if enabled)
> * 'verified' - QA has verified this version of Firefox is unaffected by the bug now that we've landed a patch
>
> I'm proposing a change and a couple of new additions to the status flag:
>
> * add the 'disabled' status flag to denote when code change has been taken but is disabled (through a default preference or otherwise)
> ** 'fixed' would then mean implemented&enabled instead of just implemented
>
>
> * add the 'disabled' status flag to denote when code change has been taken but is disabled (through a default preference or otherwise)
> ** 'fixed' would then mean implemented&enabled instead of just implemented
>
> * change 'verified' -> 'verified fixed' so that QA can verify when a feature/fix is implemented and enabled
> * add 'verified disabled' so that QA can verify when a feature/fix is implemented but disabled, confirming that there haven't been any functional changes in the user experience
>
> * add 'verified disabled' so that QA can verify when a feature/fix is implemented but disabled, confirming that there haven't been any functional changes in the user experience
>
> The end goal is to be able to look at the main feature bug and immediately know its full status across releases. I'll wait for feedback here before filing a bug to cover a bugzilla change. Thanks!
>
> -Alex
>
> -Alex
0 new messages