On Wed, Mar 5, 2014 at 6:51 PM, Jonathan Riddell <[email protected]> wrote: > On Wed, Mar 05, 2014 at 06:41:58PM +0100, Harald Sitter wrote: >> On Wed, Mar 5, 2014 at 5:58 PM, Jonathan Riddell <[email protected]> wrote: >> > On Thu, Jan 30, 2014 at 12:38:45PM +0100, Harald Sitter wrote: >> >> On Wed, Jan 29, 2014 at 6:17 PM, Jonathan Riddell <[email protected]> >> >> wrote: >> >> > >> >> > What does support mean at all in respect to a Kubuntu release? We >> >> > don't spend time fixing bugs in old releases generally. But if a fix >> >> > is available and is requrested by a friendly user we should do the >> >> > update. >> >> >> >> How would a user request a fix though? Usually that is a bug report, >> >> but we have a policy to move upstream reports upstream unless they are >> >> of considerable importance to us. So really there is no forum for the >> >> user to request a fix backport. >> > >> > We should evaluate any bugs to check if they are of considerable >> > importance to us before moving upstream. In reality someone is more >> > likely to ping on the mailing list or irc. >> >> What is an important bug then? > > It's subjective but generally one guideline is one which if not fixed is > important enough to be release noted.
Raising the question what qualifies a bug as important enough to be release noted. That also seemed a bit "oho, the day before release I found this bug report in my inbox, we should have a release note for it" at times ;) ^ perhaps that should also be defined in some policy. Off the top of my head I'd say: - package is on the ISO/package-set or visibly promoted (e.g. the featured apps in discover) - bug breaks core functionality of the application (e.g. crash on startup or crash whenever one tries to use the core functionality, like trying to hit play in amarok) - OR bug hinders intended UX of the core functionality (e.g. amarok constantly popping up a messagebox when the track changes) - OR bug is causing substantial (relative) amounts of automated crash reports on errors.ubuntu (random number: top 5 crashers subscribed by kubuntu-bugs) - OR upstream requests the bug to be noted and resolved - AND upstream is aware and investigating ^ those are upstream bugs that *may* be tracked on launchpad for general interest and book keeping and eventually result in release notes when not resolved in time. since upstream must be aware and investigating we can expect some sort of fix at some point in the not too distant future which ultimately means that those types of bugs will and should not be open for more than 6 months and as such also perfectly align with the LTS policy as per the current draft. I actually have a definition for core functionality in case you are wondering (the dead upstream policy also mentions this concept, but I decided not to define it there as the dead upstream assessment can do with some leeway as it comes down to the developer's judgement at the end of the day): Core functionality of an *application* (note application, libraries are to be excluded; either a bug in a library afffects the core functionality of an application or it will not qualify) are all things one can see when opening the application (excluding menubar) as well as everything necessary to deliver basic core functionality. To give some examples for latter: - amarok is a music manager and *player*, hence playback is a core functionality as well as the collection - kde telepathy is an instant messaging system, hence the messaging must be working (although not part of the contact-list default view) - k3b is a burning application, hence it must be able to burn any old CD (also, technically not part of the default UI) In addition to that, the draft for Stable Updates outside the SC update policy explicitly allows a user to request a SRU for every bug that has a known upstream resolution as long as the target series is either current stable or the user is able to find testers for all supported release back to the one he wants the SRU for. So, this should permit your original assertation that we'd push an SRU if a user requests one, as those bug reports are then not considered actual reports but requests for a SRU (i.e. upstream fix is available, so as long as the testing requirement is met there is no reason not to resolve the request). HS -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
