On 1 April 2010 22:23, Marcel Rieux <m.z.rieux@xxxxxxxxx> wrote: > On Thu, Apr 1, 2010 at 5:06 PM, Chris Adams <cmadams@xxxxxxxxxx> wrote: >> >> Once upon a time, Sam Sharpe <lists.redhat@xxxxxxxxxxxxx> 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 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
