FPL steps down: what's the real story?

[Marcel Rieux]

On Thu, Apr 1, 2010 at 5:54 PM, Sam Sharpe <lists.redhat at samsharpe.net>wrote:

> On 1 April 2010 22:23, Marcel Rieux <m.z.rieux at gmail.com> wrote:
> > On Thu, Apr 1, 2010 at 5:06 PM, Chris Adams <cmadams at hiwaay.net> wrote:
> >>
> >> Once upon a time, Sam Sharpe <lists.redhat at samsharpe.net> said:
> >> > You keep saying this. I shall make only two points as I am bored of
> >> > saying this time and time again.
> >>
> >> I would welcome you stopping saying this, since you present two extremes
> >> as the only possible choices (which they are not).
> >
> > Though I've been providing this link time and again, Mr Sharpe has chosen
> to
> > ignore it:
> >
> > https://fedoraproject.org/wiki/Stable_release_updates_vision
>
> Actually I read it before, although I have no idea whether it was due
> to a post by you  - I believe it to be largely a statement of the
> current status-quo. Perhaps you read it differently to me.
>
> *  The update repositories for stable releases of the Fedora
> distribution should provide our users with a consistent and high
> quality stream of updates.
>
>    I haven't seen huge issues with updates for releases. I realise
> other people might have, but that doesn't indicate an endemic problem
> of brokenness in Fedora, nor that the aims have changed.
>
> * Stable releases should provide a consistent user experience
> throughout the lifecycle, and only fix bugs and security issues.
>
>   Again, I haven't personally seen evidence that Updates to a Fedora
> release have massively changed the User Experience - but then I'm not
> a KDE user.
>
> * Stable releases should not be used for tracking upstream version
> closely when this is likely to change the user experience beyond
> fixing bugs and security issues.
>
>    This is currently true - they do not.
>
> * Close tracking of upstream should be done in the Rawhide repo
> wherever possible, and we should strive to move our patches upstream.
>
>    This is the current situation
>
> * More skilled and/or intrepid users are encouraged to use Rawhide
> along with participating in testing of stable branches during the
> development and pre-release period.
>
>    This is the current situation
>
> * Stable releases, pre-release branches, and Rawhide have a graduated
> approach to what types of updates are expected. For example, a
> pre-release branch should accept some updates which a stable release
> would not, and rawhide would accept updates that are not appropriate
> for either a stable release or a pre-release.
>
>    This is the current situation. e.g. major software versions can
> change between F12 Alpha and Beta releases.
>
> * Project members should be able to transparently measure or monitor a
> new updates process to objectively measure its effectiveness, and
> determine whether the updates process is achieving the aforementioned
> vision statements.
>
>    Not something I can comment on.
>
> As I understand it, in the above terminology:
>
> Rawhide == Rawhide
> Pre-release == Fxx Alpha, Fxx, Beta, Fxx RC
> Stable == Fxx
>
>
So! No more  'The "Stable" offering is Red Hat Enterprise Linux.' ?

What? OK, RHEL might finally prove more solid than Fedora, but final is
stable. Only security patches and important bug fixes should be uploaded. No
program updates. I'm glad to learn we agreed all along!

Which means that, for instance, developers should think twice before
quitting the KDE 3.5.x branch and going for 4.0. Since testing means "going
soon to the final, stable release", KDE 4 remains in rawhide, even though it
evolves to new dot versions, until it's deemed stable enough for the next
final release. That's the way Patrick Volkerding does it for Slackware.

For non-developers using Final , "release early. release often" is "released
too early, released too often."

Of course, nothing prevents Red Hat's own geeks, or anybody feeling
adventurous, from enabling the Rawhide repository.

So, everybody is kept happy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/users/attachments/20100401/04ebf94f/attachment-0001.html