> > > - unstable lockdown in the freeze > > > - drop Testing and concentrate on work instead of wasting time on > > > synching stuff. This eliminates the need for testing-security. See > > > the last part of the paper for details. > > > > Doing this would result in many users who currently run testing fall > > back to stable + backports or switch to another distro (ubuntu being a > > likely candidate), which in turn, would result in less bugreports and a > > less stable distribution. I, for one, wouldn't run unstable on my > > parents' box, whereas testing proved to be quite reliable there. > > Ehm... what is wrong with running stable with backports? Why do you not > install a such combination for your parents, what is wrong with that? > > - Missing few important pieces of software? Backport them
That takes some effort, especially when the new version in unstable build-depends something bigger (I remember how hard it was to backport some debhelper-using stuff without backporting all of perl - I do not want to backport large pieces of unstable). I do not have the time and energy to do those backports. Nor do I want to upgrade half the system, nor is any security support for backports as far as I know. Not officially, that's certain. (Yes, there isn't one for testing either, but most of the case I can just grab the new package from unstable and be done with it, while it's not that easy using backports). And even if I could do it theoretically, J Random User who is running testing (because stable is too old) would not be able to do the backports himself, whenever he needs something that is not backported already. > - all the packages are out of date? Well, though luck, this is what the > whole issue is about. We need to release faster. Faster releases are > only feasible if enough developers are motivated. They are motivated > if Unstable is blocked and they must care about the release instead > of working on stuff that makes "more fun". No, they are NOT motivated if unstable is frozen. Did we get potato out sooner than sarge? I don't think so (I may be wrong, though, it was quite some time ago, and I was only lurking on the lists back then). I do remember though, that I, as a mere mortal user was very upset about unstable being frozen. I was running it to get the latest and greatest software to play with, and when that excitement was taken away I felt a bit cheated. You take away the toy, and whoever played with it, will find another one, and since he's angry at you, probably not the replacement toy you offer. (Ie, freeze unstable and I'm sure to go and ignore Debian until there's a release - not that I do anything for the release anyway, so it probably wouldn't matter, but still) Getting people motivated should not be done in a way that makes - I hope - many of them unhappy. To get back to your point - blocking uploads to unstable will not make more people concentrate on the release. They'll surely find something else that "more fun": it's not "release or uploads", it's "release or uploads or something else". Those who do not give a damn about the release, will not change their mind when unstable is frozen. Motivating people means getting them interested in the release, making the process "more fun" for them. Or at least less of a nuiseance. Freezing unstable will add to the annoyance level, instead of taking away from it. > > Freezing unstable will get you nothing compared to what we have now. > > What do we have? Release times reaching eternity? Testing, full of > hidden / obscure bugs that have not been visible in Sid, or that are > fixed in Sid but the update got stuck somewhere? So you propose that those hidden / obscure bugs will only surface when stable comes out, because there was no testing where they could be observed earlier? How, pray tell, is that better? How was potato's release any better than today? Except that the arches had to be kept in sync "manually", without the help of testing. For updates, that are important enough but got stuck, there is testing-proposed-updates. Once there are (security or other) autobuilders for testing, one uploads a package there, it gets approved, everyone's happy. Little more work on the maintainer's part, but you'd have to do roughly the same, would unstable get frozen. With the additional burden on the release managers that they would need to check EVERY proposed upload. Now they only need to check a smaller amount of uploads, since unstable - and even some parts of testing - are open still. What you propose places even more burden on the release managers, even more stuff to deal with. They will not get motivated by this, not at all. Ways to make the current system better - THAT would be very welcome. Like enhancing the logic of the testing scripts, which decide when and how a package migrates from unstable to testing, so migrations could get faster and large blocking stuff could be eliminated, that would help the release. Placing burden on people who already have more than enough to care and worry about won't help at all, methinks. > > Those who don't care about a release, will not care that way either, > > just their complaints will get louder and more frequent. Those who are > > How should they complain? "We cannot update foo in Sid because it has > been frozen for three weeks now, nya, nya". The answer would be some > analogue to RTFM (HTFR, help the f... release). Yes, that would be an answer. And how would that help the release? Would that answer make them more interested in a release? (No, they'd probably go back to their regular work, giving thanks to $DEITY that they don't have to care about their packages, since they won't get into sid anyway, therefore they can use the time they'd work on packages to do their paid work.) > > willing to do the work neccessary for the release are already trying to. > > Yeah... with Testing overhead throwing stones in their way. What kind of stones, if I may ask? And why not teach testing that throwing stones is a Bad Thing, instead of hiding in a cave, hoping that some day the blizzard that a frozen unstable generates goes away? > > Remember, Debian is a volunteer project, you cannot force people to do > > something they do not want to. > > Motivation is the only factor to make them do things. Having to care > about the release in order to continue the "fun work" leads to > motivation. Nope. Making unstable does not force them to care about the release. They'll find something else that statisfies them. If they don't want to care about the release, you will not be able to force them. > > > Testing synchronisation are not of pure technical nature, they are > > > social problem, and so they should be solved by people and not > > > scripts. > > > > Yes, testing synchronisation is not a purely technical matter. Nor is it > > purely social, so the testing scripts, which automatically keep stuff in > > sync, are a real help. On top of that, package maintainers coordinating > > They are overhead. How so? A release needs all architectures in sync, testing does that for us without much manual hackery. I don't see why it is so much an overhead. Agreed, it does have _some_ overhead, since a package needs time to migrate. But that's not neccessarily a bad thing. It's a compromise, and as far as I see, a good and useful one. So far I didn't hear _any_ convincing argument against it. > > with each other (the social part) is welcomed too, and should be > > encouraged. (And those who break a transition should be kicked in the > > ass, so they won't try it again :P) > > What's the problem? If you feel bored, go to #debian-bugs and help > fixing RC bugs. We could have a BSP every three days or so. There you > will have semi-social contact and can motivate each other to do the > actual work. ...and that can be done with testing in place, with all the benefits it provides. So far, the main complaint against testing is that sometimes packages get stuck. *Duh*, so fix the problem that made them stuck. That might need some social engineereing, as most of the time, stuckage is not caused by technical problems. Would you want to push the same larger update into a frozen unstable, you'd run into the very same problems anyway. -- Gergely Nagy
