What does LTS *actually* mean

[Harald Sitter]

On Wed, Mar 5, 2014 at 6:51 PM, Jonathan Riddell <jr at jriddell.org> 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 <jr at jriddell.org> 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 <jr at jriddell.org> 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