Proposed udpates policy change

[Jon Masters]

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.