Hi Matthew, Thank you to you, Josh, and others for putting effort into these discussions. And thanks for bringing this up in the meeting tomorrow. Some comments inline below that might be useful, or not. Before I get into what you wrote, can I also suggest asking Fedora users what they want? We already have an announce list, and we have things like firstboot, and the fedoraproject start page. It would be *trivial* to post a survey up on the website that most users are going to see, for the next few months, and collate actual responses from end Fedora users. If they want rolling updates, so be it and some of us are "wrong". But for goodness sake, let's actually ask the users about it. On Mon, 2010-03-08 at 21:59 +0000, Matthew Garrett wrote: > 1) Updates to stable that result in any reduction of functionality to > the user are unacceptable. Indeed. I believe this is the number one problem right now. The problem is that a single package update can introduce compound issues with other packages that were unforeseen and untested, especially the latter. This is an issue even for the "slow moving" Enterprise distros, and they have entire teams of people paid to do very thorough testing before pushing each individual update. Fedora can't quite do that, but I believe that is therefore even more of a reason to slow down the update pace. After all, there's a new release in 6 months, not years later (as would be the case with an enterprise distro). I'd rather wait 6 months for some feature than have to take time out of the day to fix a stable box. > The ability for maintainers to flag an update directly into the updates > repository will be disabled. Before being added to updates, the package > must receive a net karma of +3 in Bodhi. I believe that this is possibly too limited. Aside from the obvious abuse potential (which will always exist no matter what happens) - obviously someone could just hate the process and decide to have a couple of others sign off on everything no matter what - I think it should be necessary to have a cooling off period between pushing an update, it being voted on, and it going out live. It doesn't have to be weeks, but it should be long enough for the person who actually reported some bug to test that it is fixed and for others who aren't able to devote time every day to see the update. I suggest 3-5 days. I also suggest /considering/ implementing rolling updates rather than pushing everything to stable. By rolling updates, in this case I mean implementing a technical means (and this is tricky with mirrors) by which not every user will receive the update at once. Perhaps PackageKit already does something with random deltas for non-security updates. I usually do updates myself manually (I upgrade stable Fedora systems only when I am certain to have time to reboot, and then I will bite the bullet and apply many updates at once) so I haven't noticed that. > Defining the purpose of Fedora updates is outside the scope of Fesco. > However, we note that updates intended to add new functionality are more > likely to result in user-visible regressions, and updates that alter ABI > or API are likely to break local customisations even if all Fedora > packages are updated to match. We encourage the development of > mechanisms that ensure that users who wish to obtain the latest version > of software remain able to do so, while not tending to introduce > functional, UI or interface bugs for users who wish to be able to > maintain a stable platform. It might be worth /considering/ something like "volatile" on other distros. I know that's mostly for anti-spam type stuff. But perhaps some parallel stream similar to updates-testing where users can elect to have new features if they want them, or retain the stable release (in which case all they get is security fixes). Basically, fedora-updates becomes literally a separate stream disjoint from the regular fedora stream. Jon. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
