Hi, On Sun, 26 Sep 2010, Luk Claes wrote: > > I think that having an official "rolling" release always available would > > reduce the pressure of maintainers to always push the latest into the next > > stable release precisely because there's an alternative... so it would > > rather help concerning this point. > > We do already have experimental.
experimental is not for the user lambda, and as a maintainer I'm not so happy to have to point users to experimental if they want the latest release. > > Fixing remaining issues is a general QA problem. We must do more > > prevention so that unmaintained packages are not discovered only during > > freeze when it's too late but way sooner. > > Indeed, so I'm not arguing against having more testing of testing with > snapshots. snapshots would be less useful than rolling since they would be outdated compared to testing... more testing is good and you get more testing with more users, it doesn't matter whether they use snapshots, rolling or testing itself. > > Again it's unrelated to the existence of rolling, the problem is inactive > > maintainer not taking care of their packages and those are not the same > > that would actively push their packages to rolling. > > What do you base this on? It does not at all seem clear to me that > rolling would not introduce maintainers who only care about rolling. Nobody can predict the future... but my take is that the people who only care about rolling would be the people who do not care of testing right now already. Those who care about testing would continue to do it. > > Those maintainers have package that have not migrated to testing for a > > long time usually. > > Right, though inactive maintainers are not usually the problem as they > can be worked around (NMU). I beg to disagree. All maintainers can be NMUed... so with you argument there's no problem at all. But the truth is that we don't have enough skilled people to NMU and fix all the current problems. If more maintainers were doing their job as they should, we would have less stuff to NMU and we could release sooner. > > This fear is unjustified. The consequences are much more complicated than > > this. It might attract more contributors from derivatives which would > > benefic for the general quality and thus the freeze time. Or it might > > mean more users who discover the RC bugs quicker than we're doing right > > now with testing... etc. > > It might also attract more users that file bugs that are already fixed > or that were never in unstable nor testing. Huh? > I still fail to see why the problems with testing have to be worked > around at instead of be fixed properly. A proper fix takes time. I want the proper fix but I also want to start step by step in the not too distant future. And I want to fix the name: s/testing/rolling/. > > I can understand your fear but I think it's wrong to be opposed to the > > rolling idea on the sole ground that it might meant less people caring > > about a stable release. > > It's not only that, but also the fear that the problems we do have with > testing will stay instead of getting fixed properly... How can I dissolve that fear? I want to start with rolling and I'm fully aware that the proposal doesn't lead to the best workflow compared to something that we would have designed from scratch. But we have an history, squeeze to release and we can't do a big bang. Besides almost none of the changes in Debian have happened that way. I fully want to fix the workflow issue later on with cooperation of all involved parties and I will make proposals. A big part of CUT is also changing our communication, both internal and external: - internal to say to all contributors that testing/rolling is meant to be always usable so you must be careful in everything you upload to sid, no matter whether we're far from release or not and RC bugs are always important to fix, and you must care about migration to testing/rolling because many users will want the latest version in that distribution - external to say to users that testing/rolling can be safely used and is supported by the Debian project at large > > Of course, we must design rolling in a way that it supports testing and > > vice-versa. In the mid-long term, they might merge again but right now > > it's easier to start with a new release where we can experiment a bit > > rather than push important changes to the current release process. > > Are you talking about introducing rolling during the current freeze? I > think that would only prove my point that it shifts attention away from > testing... Besides we still need to fix the current issue we have with > chromium and similar packages before the release... I don't know when rolling would be introduced, and I don't know when squeeze will be released. If we start rolling during this freeze, we will probably only do testing + hand-picked updates to make it more usable (i.e. no automatic britney run from unstable to rolling). My attention does not shift: I take care of my own packages but I'm not one of those who are doing NMU anyway and whether or not I work on rolling will not change this. For chromium and similar packages, I don't see what proper answer you will find right now. My own suggestion is to get them in testing/stable but flag them with a tag that says "volatile" and which means that the package might get new upstream versions (with more than just bugfixes) during the lifetime on the stable release. But we need proper support in the package managers to warn users that want to avoid those packages. So for me that's squeeze+1 material and was part of proposals that I want to push later. On the opposite, if we had this flag we could decide that packages with this flag are ok for rolling but not for testing and we could have testing follow rolling with an automatic filter. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100927081650.ge15...@rivendell.home.ouaza.com
