> >* A release for general users with low volume of security fixes and > >important bug fixes. > >** Bug fixes would be pushed monthly and QA would be performed on > >this monthly batch of updates. > > Some packages need more than bug fix updates (unless you are taking a > very > broad view of what a bug is). We haven't done a very good job of > having > a consistent interpretation with the current update policy. Giving > the > proposal below, this will be a more important issue than it is now. You are right, some types of packages would deserve more frequent updates even if they are not just bugfixes. Typically end-user applications like Firefox or LibreOffice, if there is no major UI/functionality change. Fedora Stable is intended for conservative users, but it's still Fedora, so reasonable minor changes would be fine. > > >* Released every 18 months, supported for 18+2 months (2 months to > >give people time to upgrade to the next Fedora Stable). > >** Why 18 months? Because for general users it is annoying to > >upgrade every year, but OTOH our package maintainers wouldn't > >probably like supporting 2-year-old packages. 18 months is still an > >increase from current 12 months of support, but if we stop > >releasing two parallel stable releases, we can make the support > >longer with the same energy spent. > > We are going to take a marketing hit doing this. Probably yes. But, to tell the truth, we're getting a lot of marketing by postpoing F18 as well. There might be a lot of other ways to do marketing. > > >** Just one stable release instead of two. Can anyone tell me a > >compelling argument for having two stable releases (F16, F17) in > >parallel? I don't see any. The current model probably evolved > >because we wanted new software fast, but upgrading every 6 months > >would discourage a lot of users. Let's be honest - yes, it will > >contain old packages and yes, it is intended for conservative > >users. For the other group we will have Fedora Rolling. > > We provide extra flexibility in letting users decide when they want > to do > upgrades to stay in support. It's not only letting them use a release > for > about a year if they want, but also to do the upgrade at a time where > they > can conveniently deal with any issues. That's a good argument. Currently they have 7 months to do the upgrade. With my proposal, they have 2 months. Unless they want to run a system without security patches for some time. So maybe we could extend the time we provide security patches? > > >* More reliable upgrades, although less convenient for power users. > >Instead of current way of often-broken system upgrades, our upgrade > >tool would install a clean system, remount /home, and try to > >install all GUI applications that the user had manually installed > >in his previous system. > > This seems to be independent of the proposal to have only one stable > release. Right. > This tool is still not going to be able to do magic and there will be > config > things that still need to be redone. Third party repos will still be > an issue. It's a clean installation, I don't think it needs any magic. Also third-party repos are not a problem, we just ignore them and they won't influence the new system. People will add them manually again once in 18 months. > >** This process would also allow Anaconda devs to continuously work > >on the installer and update it continuously with core system > >changes. Currently they can't work on Rawhide because "Rawhide is > >just broken". Fedora Rolling would allow them that. > > I don't think that is the issue. They work in branched because they > don't > have the man power to also be working in rawhide at the same time and > since > anaconda is sensitive to the version of other packages, they want to > be > developing against what's going to be in the next release. > Yes, but this would reduce the surprise moment when Fedora is being Branched and Anaconda team discovers that 1337 things changed in Rawhide since the last stable release. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
