Kubuntu LTS

Jonathan Jesse jjesse at gmail.com
Fri Dec 28 03:31:50 GMT 2007


On Dec 27, 2007 5:32 PM, Luka Renko <lure at ubuntu.com> wrote:

> On Monday 24 December 2007 11:43:59 Scott James Remnant wrote:
> > Hi Luka,
> >
> > The Technical Board was not formally involved[0] in the decision whether
> > or not to release Kubuntu 8.04 as an LTS.  "LTS" is a commercial support
> > commitment provided by Canonical Ltd, who shoulder the financial and
> > administrative burden of doing so; as such, it is entirely their
> > decision as to whether or not they provide that support for a particular
> > release.
> >
> > They make the decision on a purely commercial basis, determined by
> > factors such as: the stability of the release in question; the
> > supportability of the release; the commercial interest in the release,
> > etc.
> >
> > Given that, and since the remainder are not technical in nature or
> > resolving a technical dispute, the Technical Board cannot answer your
> > questions.
>
> Thank you for making this very clear. In early discussion, Technical Board
> was
> mentioned a lot (as the authority to explain the decision) and this is why
> I
> have put it on Cc for clarification.
>
>
> > However since I was involved in the decision-making process at Canonical
> > as part of my job as leader of the Ubuntu Desktop team, I will attempt
> > to answer your questions as best I can.  The rest of this e-mail shall
> > not be considered a reply from the Technical Board.
> >
> >
> > Kubuntu 8.04 comes at a difficult time in the KDE release cycle, it
> > arrives just after the dawn of a major new release of the platform which
> > is a very significant new amount of work.  This is a new platform that
> > is receiving a significant amount of attention, both from its developers
> > and from its users.
>
> I completely understand KDE4 brings new momentum and therefore needs to be
> taken into the picture. My concern is that such thinking and decision is
> made
> that late in Hardy schedule (even more being LTS targeted release).
> Everybody
> kind of expected that situation was clear after UDS in Boston (where all
> blueprints mention KDE 3.5 being the default also due to LTS badge).
> Since KDE4 position did not change much after UDS, it is even less clear
> why
> the approach was changed later.
>
>
> > Questions that were asked:
> >
> > Will KDE 4 be stable enough to support for the term of the release?
> >   I've not seen anybody who believes that this would be the case; a
> > long-term supported release would have to be based on the stable KDE 3.5
> > series.
>
> Agreed and also supported by Hardy blueprints as defined on UDS.
>
>
> > This gives us the second question:
> >
> > Will a bug in KDE 3.5 receive upstream attention in March 2011?
> >   In order for Canonical to make a commercial commitment to their
> > customers, who have signed contracts and terms of service with them,
> > they need to be sure that they can honour the terms of their agreements.
> >   The KDE upstream position appears clear, KDE 4 is the focus of
> > developer attention; KDE 3.5 will be supported as long as KDE 4 isn't
> > suitable for support.
> >   Given the attention being paid to KDE 4, it is difficult to believe
> > that this will not be the preferred release in three years time.  Thus
> > it is difficult to guarantee that upstream will still support the
> > current stable series for the timescale required.
>
> Canonical for sure can best evaluate their existing customers that are
> paying
> for support of Kubuntu and need to ensure that they can follow terms of
> service.
> On the other hand, I do not see where the claims that KDE 3.5 would be
> completely unsupported very soon (by upstream and other actively
> supporting
> it today). We have to be aware that there are other commercial offerings
> based on KDE 3.5 and at least one response [1] makes it very clear that
> there
> are other companies besides Canonical that will have to support KDE 3.5until
> 2011 (extended support even until 2013) - not to mention that this
> particular
> company have several payed KDE developers on staff that supports such
> claims.
> Taking into account that KDE 4.0 is not even feature-wise on par with 3.5
> (and we all hope this will be not as big issue with 4.1) and that it is to
> some extend revolutionary (and not just evolutionary) upgrade, it is
> expected
> that more conservative customers would appreciate having stable, supported
> KDE 3.5 distribution based on Debian.
>
>
> > Is the development community able to sufficiently test the new release?
> >   Again, in order for the commercial commitment to be made, Canonical
> > has to believe that the development community (which includes its own
> > staff) are able to provide sufficient testing of both the new release
> > and upgrades between older releases and the newer one.
> >   This judgement is both based on the number of active testers for the
> > previous release according to the ISO test tracker, and the relative
> > popularity of the available packages/seeds.
> >   The number of Kubuntu developers testing releases and recording their
> > results is right now at an all-time low, this makes it difficult to
> > guarantee sufficient test coverage of installs and most importantly
> > upgrades.
>
> It is clear that Canonical has currently one full-time KDE developer on
> staff
> (even though lots of other Ubuntu developers contribute a lot also for
> Kubuntu features) and I can understand it has to prioritize how to use the
> limited funds. I would also personally like to thank Canonical for all
> resources that have bin put in past years into Kubuntu.
>
> But you have uncovered another point which seems to have influenced the
> decision: community involvement in testing releases. I was completly
> unaware
> that this has become an issue (myself being active in Ubiquity/ISO testing
> in
> past releases), even less being seen as major concern for Kubuntu in
> general.
> If this is seen as showstopper for proper Kubuntu support by Canonical, it
> would be good if these concerns would be communicated to Kubuntu
> community.
> Since we have Kubuntu Community Council, it looks like the right forum to
> address such issues.
>
>
> >   Likewise the current download interest is entirely directed towards
> > KDE 4 packages and CD images.
>
> That is good to know, but we have to be aware that KDE4 is hot topic and
> lots
> of people download it to preview new technology and that LTS is anyway
> targeting very different customer base. This have been seen also in this
> thread on the mailing list and blogosphere, with several responses by
> users
> (and not just Kubuntu developers) that they have cleary choosen LTS for
> good
> reasons (they cannot cope with 6-month upgrade cycles...)
>
>
> > I hope that provides some insight as to how this decision was made,
> > expanding on the statements that Jonathan made in his announcement.
>
> It does and I would really like to thank you again for discussing it with
> the
> community.
>
> > As to your questions about the timing, method and discussion for the
> > decision:
> >
> > The community's input was actually sought on several points, and many
> > members of the Kubuntu community provided answers and insight that
> > contributed to the decision.  It is difficult for this decision to be
> > made by the community because the community's stake in Kubuntu is one of
> > personal achievement and pride, whereas Canonical's is financial and of
> > commercial commitments.  Had Canonical simply asked the community
> > "should Kubuntu 8.04 be an LTS?", the answer would not be based on the
> > same terms: instead more direct questions were asked such as "how long
> > will upstream work on KDE 3.5?"
>
> I am fine with the fact that it is up to Canonical to make the decision
> about
> what level of commercial support it will provide. Concerns of the Kubuntu
> community are only with the fact that decision might have been made on
> questionable base and with wider impact on Kubuntu positioning in general.
>
>
> > The timing of the decision was simply based on when it was clear from
> > the KDE release schedule that it was inevitable that KDE 4 would be
> > released before Kubuntu 8.04.  Since the KDE upstream release schedule
> > is not in alignment with Ubuntu's own, it is difficult to align such
> > decisions to it.
>
> Again, situation regarding KDE4 did not change that much from October
> (when
> UDS was planned) until end of the year (when decision was made) that could
> explain such change in strategy regarding Kubuntu LTS.
> Even though I am a supporter of fixed schedules myself, I can understand
> why
> such approach is even less appropriate for KDE 4.0 (being major platform
> upgrade/change) - I still hope future KDE 4.x releases would be more
> predictable. On the other hand, I never had a feeling in past that Kubuntu
> developers were not able to get latest&greatest stable KDE release into
> Kubuntu (and I am using Kubuntu from first Hoary release and contributing
> since Breezy).
>
>
> > As to the unclear reasoning behind the decision, there is insufficient
> > argument in your e-mail to answer that since you don't discuss where you
> > feel the communication is unclear.  The announcement states that the
> > reason is that KDE 4 will be released before Kubuntu 8.04, that it is
> > the focus of user and developer attention, and that this upheaval is
> > contrary to Canonical's requirements for an LTS.  This is the reasoning.
>
> Again, nobody thinks that KDE 4.0 should be considered for LTS, I would
> personally leave it in universe for Hardy, allowing more people to
> contribute
> to it. KDE 3.5 is very stable and will not receive much new features, but
> it
> is still receiveing bug fixes (you can check in SVN) and I am sure at
> least
> 3.5.9 is around the corner (even candidate for Hardy). By definition, I
> would
> expect this would make it even more suitable for LTS.
>
> I have another concrete question for Canonical: will Kubuntu Hardy be
> still
> available through ShipIt? Will ShipIt support only KDE 4.0 or KDE 3.5 or
> both? As you have probably seen in Planet Ubuntu, there are already
> different
> stories regarding this topic (ranging from KDE 3.5-only, KDE 4.0-only and
> providing option for user to choose from) and this is causing quite some
> confusion.
>
>
> > Your other questions only have answers in further questions:
> >
> > Kubuntu will be suitable for an LTS when the KDE packages it contains
> > are expected to be stable, maintained and supported for three years
> > afterwards.  (This could be considered LTS requirement zero; 6.06 came
> > at a perfect time, it is hopeful that KDE 3.5 will at least have some
> > remaining support and maintenance for the next 18 months while it
> > remains supported.)
>
> Skipping one LTS release for Kubuntu has wider impact than just not having
> 3-year support for specific release:
>
> 1. Introduces uncertanty for existing Kubuntu users (and not just LTS
> users)
> Will I need to upgrade every 6-month now? What support (from Canonical)
> can be
> expected in future? Will there be Kubuntu LTS in future? Can LTS be
> expected
> with next release (hardy+1, 8.10?)?
>
> 2. Makes even more differentiation between Ubuntu/GNOME and Kubuntu/KDE
> It is clear that priorities were set much before Kubuntu was introduced
> with
> Hoary, but such decisions just strenghten the view that Canonical/Ubuntu
> does
> not really care about Kubuntu (see [1] for example).
>
> 3. Sends bad message to KDE developers (and Kubuntu community)
> Canonical does not trust KDE 3.5 as being stable/supportable for 3-years
> (even
> though past version were considered as good enough). Kubuntu is used by
> lot's
> of KDE developers and good KDE4 packages just strangthen this position.
> Dropping support level for stable 3.5 release does not help in this.
>
> I am not sure if above concerns were part of your decision making, but for
> sure that they should be. And I think it should be taken into account when
> Canonical will communicate LTS decision to wider public.
>
>
> > No claim or commitment has been made to how LTS upgrades will work; the
> > intent is that one LTS is directly upgradable to the next, however this
> > requires extensive testing on behalf of the development community.
>
> We all understand upgrade issues are big even between 6-month releases,
> not to
> mention 2-year releases as it is currently the case with LTS. Skipping one
> LTS for Kubuntu just increases the probability that such upgrade would be
> very hardly achievable, as even the common parts (shared with Ubuntu)
> would
> need lot's of special treatment which I really doubt it will make sense
> for
> Canonical to do just to cover Kubuntu LTS -> LTS upgrade.
>
>
> > I cannot answer KDE 3.5 to KDE 4.x upgrade questions, those are
> > technical.
>
> Yes this is separate story and will for sure require nice blueprint on
> next
> UDS. ;-)
>
> I would also like to stress here that it would be good if Canonical would
> make
> official statement for Kubuntu users regarding LTS decision: currently all
> information is discussed on IRC, kubuntu-devel mailing list and
> blogosphere
> and I am not sure that different personal statements with interpretations
> by
> Kubuntu community members are helping in clarifying the position.
>
>
> Thanks again and I wish you and your family all best in 2008,
>
> Luka
>
> [1] http://www.kdedevelopers.org/node/3167
>
> --
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>

Luka,

You have stated all my concerns and possible frustrations that I have heard
and have also voiced myself in only a much better way then I thought
possible.  I have heard some of the same questions both on the blogsophere
and also on IRC.  I am looking forward to the next version of Kubuntu
whatever it status is.  Now just have to figure out how to document it all,
especially for the next version of The Official Ubuntu Book
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20071227/aee5215f/attachment-0001.htm 


More information about the kubuntu-devel mailing list