> The entire QA team (and the entire anaconda team, for that matter) is
> currently spending virtually all its time trying to help bash the new
> anaconda into something vaguely resembling shape for a fairly
> arbitrary
> release deadline, so we can ship something called 'the Fedora 18
> stable
> release' without *completely* corpsing Jimmy Fallon-style as we do
> the
> release announcement ("suuuure, this is a stable release..." *giggle*
> *giggle* *guffaw* *full-blown laughing fit*). We've barely looked at
> the
> desktop or the update mechanism or anything else. Stuff in Fedora
> regresses all over the place...there all sorts of weirdness in how
> fairly basic bits of our OS work, like updates and login and various
> other crap. We can't really look in a mirror and say that, say,
> Fedora
> 17 is a serious stable operating system release by any reasonable
> definition. It's a stable Fedora release, and we all know what that
> is.
> We had a feature for a smooth boot process back in F12, remember?
> where
> everything was polished and had the same background and you didn't
> see
> any mode transitions? How's that working these days? It was supposed
> to
> be a feature of our operating system. We almost got it done for one
> release, and have been consistently regressing it ever since. That's
> not
> what stable, mature operating systems do.Adam is telling the inconvenient truth here, and I agree. We really shouldn't pretend that Fedora is a "stable OS". Unfortunately none of Linux distributions really is (now talking about desktop distributions, not server ones). But... the fact we're doing a poor job doesn't mean that some "general users" are not using Fedora happily. They may the lucky ones (no update breakages) or they have a power-user friend who help them from time to time. If we cut them off completely, I'm afraid Fedora would become a niche distribution, with just a fraction of its previous user base. I think that wouldn't be a good outcome. But I agree we need to simplify things and decrease the currently required resources (QA, package maintainers, releng, etc) so that the quality can go up. My idea would be to have two releases: == Fedora Stable == * 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. * 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. ** 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. * 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. ** General user wouldn't see a difference, but we could achieve much higher upgrade success rate. ** Power users would have to manually transfer /etc changes, add custom repos, etc. But if you need to do that only once every 18 months, it's not so bad. Also, a lot of power users would use Fedora Rolling instead, so they would not be affected at all. Some power users can even do unsupported yum upgrades (as many of them do now), so they won't be affected by it either. * There would probably have to be a stabilization period before new Fedora Stable is released. So Branched release would exist for a short time. But it would be e.g. 3 months every 18 months, instead of current 3 months every 6 months. Also, with Fedora Rolling being generally working (as opposed to current Rawhide), the period could be much shorter: 1-2 months. == Fedora Rolling == * Rolling release similar to Fedora Branched, but with higher quality standards. This would target Linux power users wanting leading-edge software. ** Bodhi karma would be used for issuing updates. Because a lot of people would be using Fedora Rolling, the quality would be higher than current Fedora Branched (where just a tiny number of people actually run it and report problems). * Big disruptive changes (like usrmove or sysv->systemd) would be allowed to happen just in a concrete time slots, e.g. once a quarter. ** A special tool would be required, because not every change can be performed using just RPM packaging. ** The changes would be heavily tested by QA beforehand. ** Further package updates would be blocked until you finish the disruptive change. * Installer images would be released as needed. For example after a big disruptive change happens, we would release a new installer image so that folks don't have to install the system and then immediately go through the disruptive change. ** 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. ** Transitions Fedora Stable -> Fedora Rolling wouldn't probably be officially supported, the same issue as for usual upgrades - too many things can go wrong. == Appendix == Q: What would happen to Rawhide? A: There might be technical reasons why we need a repository for pushing bleeding-edge broken packages. If there is such reason, Rawhide would stay, but we would make clear it is just a _repository_ full of bleeding-edge packages, but it is not a _release_. So it is not intended to be run, it just a repo for fixing building problems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
