Hi, Julien: On Wednesday 05 August 2009 20:42:03 Julien BLACHE wrote: > Manoj Srivastava <sriva...@debian.org> wrote: > > Hi, > > >> From the very start of the Debian Project, Debian has been different > >> from everything else: different package management tools, different > >> philosophy, different organization, you name it. > > > > But most of these will not be lost if we have a time based > > I think we'll lose part of the "we release when it's ready" philosophy > (that our RMs seem to despise so much). Because part of this is to > freeze when it's ready.
Not at all if done properly. Freeze on a date simply means that what it's ready on that date is included, what it's not ready won't be included, simply as that. When you couple that with a freeze date well known in advance, you allow interested people to plan properly. In other words: freeze on december the first doesn't mean that if, say, Gnome will publish it's new shiny 1.2 version by december the 15, the last beta should have to be included, but that the december version will ship version 1.1 (or whatever is the previous known to work stable). It's up to the upstreamer to decide if next time they will publish by november the 15th instead of december the 15th so their latest greatest gets to be shipped. The fact that they'll know well in advance when the freeze is to be expected is what will allow them space enough to make a savvy decision while now, with the "freeze when ready" is a matter of luck and a point of friction (pleeease, wait for another two weeks for our new and shinny). > A time-based freeze could mean for some teams that they'll have to > stop work basically for months to a year. It already takes too much > time to recover after a release, this won't help. Why? I really don't see your point unless you mean for the packager under current conditions where no real branches are allowed on Debian (but the everbody's bag that it is 'experimental' that has demonstrated not to be a solution at all). This needs to be changed and I expect the time-based freeze to be the tick that will finally push this change. I envision a system where a new upload will create kind of a branch and trigger a dependency cascade where all dependent (depend, suggest and recomend) packages are alerted so their maintainers can test for obvious problems and ack the upgrade or release a new change on the branch that again triggers the dependency cascade for its dependants. Once everybody acks or upgrades the whole branch gets commited into what currently is "testing" (the ack mech will in turn help for the MIA case: an unanswering maintainer would -under proper conditions, automatically meant for the package to be orphaned or even retired; a maintanier whose last package goes that way would be automatically marked for MIA process). This way, you could freeze testing almost any day without problems (and Ubuntu could easily go on their own if in the end that's better for their interests, since the health of testing would be much better any day going almost without the "upgrading storms" current process almost guarantee on testing from time to time). If that's what you meant, I think you don't have an argument against time-based freezes but against the "first time-based freeze on Dec-2009" but to push it to a latter date in order to have time for the tools to be developed (hey, Mr. Canonical, there you have a very interesting case where your hands and moneys would certainly be more than welcome). > In this day and age, you have to look at features in addition to the > version number, because the latter isn't necessarily very telling of > the real changes from one release to another. Major features are > delivered in minor releases nowadays... I already said that to be simply malpractice and beyond a distribution's ability to correct (while I'm with Shuttleworth in that concurrent freezes would help to "show the proper path" to upstreamers). -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org