FPL steps down: what's the real story?

[Sam Sharpe]

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

--
Sam