Mir bug importance
Daniel van Vugt
daniel.van.vugt at canonical.com
Tue Sep 10 03:37:20 UTC 2013
To assert that any Mir bug only affects a small number of people is
dangerous. As Mir is not enabled by default, and the audience is
presently opt-in experimenters, the Mir user base is still microscopic
compared to that of Ubuntu in general.
We probably have to assume that a bug "affecting" one person now could
affect hundreds of thousands of people later. Some might say "millions"...
On 10/09/13 11:30, Robert Ancell wrote:
> Note the field is actually "importance" not "severity" - thus is makes
> sense for "Power management is not implemented yet" to be more important
> than "The system is broken and cannot start" in certain cases, e.g. if
> the second only affects a small number of people and the former needs to
> be done by feature freeze.
> On Tue, Sep 10, 2013 at 2:38 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com <mailto:daniel.van.vugt at canonical.com>>
> I suspected that was the case, and I think that approach is flawed.
> By your rules, you're giving equal weighting to:
> "The system is broken and cannot start"
> "Power management is not implemented yet"
> If you mark everything as "critical" you lose sight of the fact that
> the first one is actually much more important than the second.
> - Daniel
> On 10/09/13 10:31, Robert Ancell wrote:
> Kevin Gunn, correct me if I'm wrong, but the way we were using
> bugs was
> Critical = Needs to be fixed for 13.10 release.
>  refers to the Ubuntu bug importances, not project bug
> The reason for that page is there was inconsistency between
> Ubuntu packages. As an upstream project, I don't think we have
> to follow
> these definitions.
> When you change the importance, Launchpad has the following
> for each value:
> Undecided - Not decided yet. Maybe needs more discussion.
> Critical - Fix now or as soon as possible.
> High - Schedule to be fixed soon.
> Medium - Fix when convenient, or schedule to fix later.
> Low - Fix when convenient.
> Wishlist - Not a bug. It's an enhancement/new feature.
> Which I think are good guides for how we should use them. i.e.
> = fix now, regardless of how much damage the actual bug causes. A
> missing feature that needs to be done before release could be
> or a feature that's blocking other teams.
> Note, I really don't understand the above definition for Medium,
> especially how it compares to Low :)
> On Tue, Sep 10, 2013 at 2:07 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com
> <mailto:daniel.van.vugt at canonical.com>
> <mailto:daniel.van.vugt at __canonical.com
> <mailto:daniel.van.vugt at canonical.com>>>
> As we focus on the most severe bugs, it's worth discussing
> what bug
> severity actually is. I don't want to confuse everyone with a
> detailed examination/discussion/____argument. But to start
> with, I
> think we need to agree on what "Critical" means...
> Normally critical means that the system is unusable . Good
> examples of definitely critical bugs are:
> "Mir/unity-system-compositor fails to start: Error opening
> DRM device"
> "[radeon] Graphic glitches and screen corruption (vertical
> lines) on
> XMir surfaces only"
> These are bugs which prevent the machine from being usable.
> But if
> it's not that bad, then please consider marking bugs as
> High or Medium.
> - Daniel
>  https://wiki.ubuntu.com/Bugs/____Importance
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
> <mailto:Mir-devel at lists.__ubuntu.com
> <mailto:Mir-devel at lists.ubuntu.com>>
> Modify settings or unsubscribe at:
More information about the Mir-devel