Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

Reindl Harald h.reindl at thelounge.net
Sun Nov 4 16:13:25 UTC 2012



Am 04.11.2012 17:05, schrieb Tom Lane:
> Simon Lukasik <isimluk at fedoraproject.org> writes:
>> Currently, each Fedora release is kept alive for 13(+/-) months. There
>> were dozens of threads about shortening or prolonging period -- but I am
>> not sure if something like the following has been ever discussed:
> 
>> Each N-th Fedora release -- where N%3==1 -- is alive for 7 months.
>> Each N-th Fedora release -- where N%3==2 -- is alive for 7 months.
>> Each N-th Fedora release -- where N%3==0 -- is alive for 19 months.
> 
>> Additionally, maintainers might be encouraged to push their system wide
>> changes into N%3==1. As well as they might be encouraged to make the
>> Fedora N%3==0 their best bread.
> 
> Wouldn't that just encourage 99% of average users to ignore the
> short-lived releases?  It would sure be a damn tempting approach for me.
> (Personally, all I want out of Fedora is a stable platform to get my
> work done on, and the less often I have to reinstall, the better.)

why is it not considered to change the release cycle from 6 to 12 months?

for large changes this would be daramtically less pressure to any contributor
and give time to polish the changes instead release them in hurry as often
happended (systemd, GNOME3 as examples)

IMHO there could be something done for non-destructive updates like
LibreOffice as for the kernel which is a recent one since a really
long time and it works mostly good

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20121104/a871abd4/attachment.sig>


More information about the devel mailing list