No more release schedules.

Kevin Kofler kevin.kofler at chello.at
Fri Jun 10 01:22:00 CEST 2011


On Friday 10 June 2011, Scott Kitterman wrote:
> Kevin Kofler <kevin.kofler at chello.at> wrote:
> >OK, since a lot of context apparently got lost during the message
> >passing, let
> >me just state my (personal) position clearly:
> >
> >What I think is acceptable:
> >* Module X wants feature Y, which is non-invasive and well-tested and
> >does not
> >change the user experience nor the user interface in a significant way
> >(for
> >those not using the new feature), backported and released together with
> >KDE SC 4.n.x.
> 
> This would mean Kubuntu would not be able to ship KDE point releases as
> post-release updates, which I would find very unfortunate. The rest I
> agree with.

Are your policies that anal? Sigh… :-(

I don't really see what everyone's problem is with a feature which does not 
disrupt the user experience in any way. It helps users and doesn't hurt 
anyone.

These are the current Fedora policies:
https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases
which some of us (including me) are already complaining about as too strict. 
Yet the "not introduce features" part is qualified by "particularly when those 
features would materially affect the user or developer experience".

There's also an exception process, by which we were able to issue 4.6.1 (and 
as a result also 4.6.x later; we skipped 4.6.0) as an update for Fedora 14 
(which shipped with 4.5.2). (However, unfortunately, we don't know if we'll 
continue to be able to get those updates through that process. 4.6 was not as 
seamless as we had expected; the initial testing went very well (in fact our 
regression tracker was already clear for 4.6.0, but we decided to wait for 
4.6.1 anyway), but once pushed, a few complaints popped up.) Still, it's much 
more likely we'll get one exception for 4.n.0 or 4.n.1 as a whole than 
separate exceptions for each module, it's just logistically much easier to 
deal with.

But features which don't "materially affect the user or developer experience" 
are usually snuck through without invoking the exception process; the process 
is that as long as nobody complains, it's fine. :-)

        Kevin Kofler


More information about the release-team mailing list