On Wed, Aug 03, 2011 at 02:46:06PM -0700, Clint Byrum wrote: > Excerpts from Micah Gersten's message of Wed Aug 03 12:55:09 -0700 2011: > > So, there are a couple merge proposals right now for control file > > description typo fixes for natty: > > https://code.launchpad.net/~bones/ubuntu/oneiric/gnomebaker/fix-for-818364/+merge/70234 > > https://code.launchpad.net/~bones/ubuntu/natty/radiotray/fix-for-722886/+merge/70107 > > > > The package has either been removed or fixed in the dev release, so > > that's not an issue. > > So, something like this would seeming be fine in conjunction with > > another SRU, but wouldn't qualify on its own for one if I understand > > correctly. > > I'm wondering if there should be a queue for these fix only with > > something else, or if we should just close won't fix (see SRU policy). > > > > Hmm, SRU policy may need some clarification. > > See: https://wiki.ubuntu.com/StableReleaseUpdates > > Specifically the "When" section, quoted below: > > When > > > > Stable release updates will, in general, only be issued in order > > to fix high-impact bugs. Examples of such bugs include: > > > > * Bugs which may, under realistic circumstances, directly cause a security > > vulnerability. These are done by the security team and are documented > > at SecurityTeam/UpdateProcedures. > > > > * Bugs which represent severe regressions from the previous release of > > Ubuntu. This includes packages which are totally unusable, like being > > uninstallable or crashing on startup. > > > > * Bugs which may, under realistic circumstances, directly cause a loss of > > user data > > > > * Bugs which do not fit under above categories, but (1) have an > > obviously safe patch and (2) affect an application rather than critical > > infrastructure packages (like X.org or the kernel). > > I actually think the language on the page needs a little work. Must *all* > bugs be high impact? Or are they ok if they don't fit into that "category". > > Both of the mentioned merge proposals have an obviously safe patch, > and affect only an application, not anything in the "infrastructure". > > I think peoples' time is better spent elsewhere.. but if somebody in > the community wants to spend time correcting the spelling mistakes, > our policy is not really clear as to whether or not this is ok. > > I'd propose that the policy be changed to be more clear on this matter. > > Something like this: > > > Stable release updates will, in general, only be issued in order to fix high > impact bugs. > This includes all bugs fitting into the following three categories: > > * ... security > > * ... severe regressions > > * ... data loss > > {note no bullet for this paragraph} > Low and medium impact bugs which (1) have an obviously safe patch and (2) > affect an application rather than critical infrastructure packages, will be > considered when fixed in conjunction with high impact fixes. The following > exceptions are made to the high impact rule explicitly: > > * ... LTS hardware > > * ... Commercial partner software > > * ... FTBFS
This should also be modified to include: * ... Apport package hook additions Due to the fact that the volume of bug reports come from the stable release it is often most helpful to get an apport package hook into the stable release rather than waiting up to 6 months for the development release to become the stable release. Additionally, these do not affect the core functionality of the package itself rather just how bugs are reported about it. -- Brian Murray Ubuntu Bug Master
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
