FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

[Adam Williamson]

On Mon, 2010-03-01 at 01:27 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > It seems like extra work for packagers, but in the end it kinda takes the
> > pressure off: you only *have* to ship the important fixes to /updates,
> > /backports is optional,
> 
> That's already a bad thing, users can no longer expect anything, it depends 
> on the maintainer being willing to do a backport. 

They can't expect anything currently either. We have no project-wide
commitment to what kind of updates we will ship. Some maintainers ship
version updates, some don't. There's already no consistency; this
wouldn't make things any worse.

> Now I know our current 
> policy isn't any better, 

Whoops =) pre-empted.

> but that's why I think we should more strongly 
> encourage upgrades to stable releases. 

Wasn't it your side of the argument who was arguing against telling
maintainers what to do, and saying it should be 'fun' to contribute to
Fedora? If going through a testing process before shipping an update is
sufficiently 'unfun' to be a problem, surely being required to ship
updates you do not believe should be shipped is in the same boat? Not
that I disagree the situation should be less unpredictable than it is at
the moment, but I don't see why *one* solution to this (make updates
slightly more cautious) is a terrible imposition on maintainers, but
another (make all updates more adventurous) is not.

> Yet, in practice, I still think a lot 
> more stuff gets backported in our updates repository than in those backports 
> repositories of other distros. 

Probably true (though in the case of Mandriva, maybe less than you'd
expect; it's nothing like the wasteland that is Ubuntu backports).
What's your point?

> Also because the maintainers don't have to 
> worry about a conservative updates stream at the same time. 

Er, yes they do. That's precisely what Mandriva has - twin streams, one
stable update stream, one backport stream. All maintainers are required
to provide stable updates for packages in /main. They can *choose* to
provide /backports upgrades too, but that doesn't absolve them of doing
a safe /updates stream.

> Having both, 
> we'd have to fix bugs in the conservative updates AND push backports. 

Again, Mandriva's been doing this for years, with a substantially
smaller maintainer base, without it being a problem. Obviously the
system isn't perfect, no system is; sometimes version bumps just go
through as updates because it's way too much work to maintain a
seventeen month bugfix backport list. But most of the time it works as
advertised, and has a record of causing fewer problems for users of
stable releases than the Fedora updates system has.

> Of 
> course that'd tempt maintainers to just skip the backports step. Whereas our 
> policy is to prefer resolving issues by pushing new upstream releases

Er, is it? I thought we were discussing the fact that we don't *have* an
updates policy. That may be the KDE SIG's policy, but it's not Fedora's,
as far as I know.

> Upgrading basically gives us the bugfixes "for free" 
> (in fact I usually just need to copy the specfile from devel to F-13, F-12 
> and F-11 and build for all).

Many instances have shown that it does not give us the bugfixes 'for
free'. It comes with the cost of causing regressions. That may be a cost
which we decide we want to bear, but portraying things in a Panglossian
manner doesn't help your cause, as it just makes you look like you're
denying there could ever possibly be any problems with your method.

> > and /backports users are good about knowing that sometimes what they find
> > there will be broken or have new bugs or whatever, and tend to know the
> > drill about not getting too upset and reporting them to you to be fixed.
> 
> That also sucks. With Fedora's KDE updates, users can be sure that they'll 
> be as regression-free as humanely possible and we do all we can to keep 
> their updates stable. 

Which means...when they notice something's broken they let you know, and
you fix it. What's the difference? Or are you seriously telling us
you're perfect, and there's never been any problem in any KDE update?
Your little 'as humanly possible' disclaimer suggests you're not really
saying that, but you could've made it more obvious.

> On the other hand, users of distros using the 
> backports model just get told "backports are unsupported". 

No, they don't. please don't misrepresent my words. That's not what I
said at all. What they get told is 'well, backports are unsupported - as
you know anyway because we spread that message very well and people know
what they're getting into - but give me some information and I'll do my
best to fix it'. Which usually happens.

> In fact their 
> builds of new KDE releases tend to carry only the same old distro patches as 
> the old version or even to be entirely vanilla, very little is done to e.g. 
> backport regression fixes from the branch. And KDE is just the example I'm 
> most familiar with, I'm pretty sure it's similar with other stuff that gets 
> updated in our stable updates vs. other distros' backports repositories.

That doesn't match my impression of how Mandriva at least handles KDE
backports, and there's nothing intrinsic about the /backports model that
means it must be this way. Or are you saying that if Fedora adopted a
split repositories model, you would somehow be compelled to make
the /backports releases suck? I don't understand why that would be. It'd
be all the same work you currently do, just released in a different
place.

> Another big issue is that people will be drawn to selectively picking only 
> some stuff from the backports repository while staying with the official 
> updates for other stuff, leading to an untestable combinatorial explosion of 
> possible update combinations. 

Theoretically, yeah, that can happen. In practice such situations tend
to occur pretty rarely and are addressed when they do happen. There is a
little caveat here that I should have mentioned; MDV's backport policy
discourages backports for key libraries - so no-one would push a new GTK
+ version as a backport, for instance. That'd just lead to large amounts
of pain. This is why new versions of KDE for stable MDV releases tend to
show up on KDE.org rather than MDV backports, because the new version of
Qt that is usually included would break this guideline.

> (Now I know people can also selectively update 
> from our updates, but if things break, I can just tell them that selective 
> updates are not supported and that they should run "yum update" and come 
> back if their problem still happens after that.)

So, 'they just get told it's unsupported', as you suggested was a bad
thing above? :)

> > And they know they can easily fall back to what's in /updates if they find
> > /backports to be broken; it gives them an escape route.
> 
> That's the only advantage of that model, 

No, it's a side benefit. The main advantage is that those who want
stable updates can have stable updates, and those who want adventurous
upgrades can have those.

> I'm not sure it's worth the 
> drawbacks.

As I said, if we are happy to jettison many users who'd prefer more
stable updates, you're correct. If we'd rather keep those users, you're
not. That's the underlying question.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net