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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
