Stable vs. Release vs Devel Was: KDE update - no testing period?

D Canfield canfield at uindy.edu
Tue Feb 14 16:27:31 UTC 2006


Jeff Spaleta wrote:
> What is the incentive to make sure ALL the peices integrate together
> nicely at any given point in time.. unless there are set release dates
> to shoot for? A release schedule drives integration efforts to make
> sure all the pieces work together. You can't just throw chunks of the
> development tree over the fence into stable, you have to deal with
> integration issues across subcomponents by having freeze points.
>   
And that all makes sense.  My point is that after the software is frozen 
and released, it seems to the revert back into an open development tree, 
with no rules as to what gets released except "try not to break stuff."  

> Do you really want to see a full rebuild of ALL packages in your
> "stable" tree because a new compiler landed in the stable tree forcing
> everyone in the userbase to download and install the ENTIRE installed
> packageset as updates? Do you really want to see users who have been
> relying on how the fc4 styled automounting worked via hal policy files
> and fstab-sync.. suddenly find the automounting working in a
> completely different way regardless of desktop because the new hal
> stuff moved into your "stable" tree? 
Not at all.  My "proposal" about the rolling releases was not meant to 
be taken seriously.  I was trying to illustrate a point that when some 
people talk about trying to stabilize things and make life easier on the 
users, there is always someone waiting to proclaim that "Fedora is an 
agressive developer's release and things break.  Deal with it or switch 
distributions."  (And that's why I included the "rhetoric" about actual 
users not being important to FC in my previous message.)

> In the large scale view of Fedora Core.. KDE is NOT a critical
> subcomponent of the fedora software stack. It is OPTIONAL and how it
> is treated in terms of updates compared to other much more integrated
> components can not be fairly compared. 
It's in Core.  How are end users supposed to know it's a second-class 
component? Or is this one of the times that end users just have to deal 
with things changing and leave if they don't like it?  (FWIW, I'm not a 
KDE user, so my interest is only in improving FC's policies and procedures.)

I'm sure I'm coming across in all of this as an argumentative sap.  But 
as an avid reader of fedora-devel for several months, I still don't 
usually know what to expect from the project.  It honestly feels as 
though people flip-flop between the arguments that "we have to do it for 
the users" and "FC is a development project" interchangeably depending 
on what best justifies a course of action they want to take.  And the 
truth is that I don't care which route the project takes.  I just wish 
some of the goals and plans would be better defined, documented, and 
followed.

DC




More information about the test mailing list