Re: Future releases of Debian
On Mon, Jul 21, 2003 at 10:52:13AM -0500, Drew Scott Daniels wrote:
> On Sun, 20 Jul 2003, Adrian Bunk wrote:
>
> > On Sat, Jul 19, 2003 at 10:39:20AM -0500, Drew Scott Daniels wrote:
> >
> > From a user's point of view it doesn't matter whether the lack of
> > security updates is due to technical problems or due to missing man
> > power - all that matters is that security updates for testing are
> > currently not available.
> >
> You missed my link. They are currently available through t-p-u, but not
> through security.d.o. I seem to remember aj arguing for security.d.o
> needing to have a testing queue and Joey arguing against it. There was a
> long thread about this recently. Just as it should be in a volunteer
> organization, if more people step forward to help, more will likely get
> done, i.e. if someone steps forward to help make security updates for
>...
Yes, Debian is a volunteer organization.
Debian isn't used only by hackers. There are users of Debian who have
neither the time nor the knowledge to work on security updates.
Fact is:
There are no regular security updates for testing available.
> > You talk about your personal "date estimate" and " Sarge will likely
> > 'freeze'". The last sentence is in the passive form. Unfortunately, a
> > freeze doesn't happen by itself, it's something that must be actively
> > done. Besides this, it's also important for maintainers to know early
> > enough when the freeze will definitely happen - a freeze short time
> > after the latest GNOME beta has entered unstable or a new major release
> > of gcc was made the default compiler is quite useless.
> >
> Colin Watson talked about a freeze state of mind. In the past the first
> steps of a freeze involved policy and on which packages should stay in.
> With the new testing distribution this step is sort of already happening.
Check the facts:
- woody was the first first release where testing was frozen
- the woody freeze started with a policy freeze
> If a new version of package x comes out after a formal freeze then we
> already have in place a way of dealing with that. I think it's important
> to get things ready for a freeze so it can be as short as possible and all
> the packages can be "the latest [stable] package" within the time period
> of the freeze. As to your GNOME and gcc an argument... if the beta is that
> bad then it shouldn't have gone into unstable let alone sarge. I'll agree
> however that sometimes packages that are in a bad enough state do go into
> unstable... sometimes for good reason, sometimes not, but at least we have
unstable is unstable.
If a freeze doesn't happen in the near future it's often a good idea to
put the beta version of a package into unstable: This way this beta gets
a better testing by the fearless people who use unstable and many bugs
are shaken out before the first stable release.
> the RC bug mechanism for making sure that they aren't horrid. Do you have
>...
"the RC bug mechanism" gives some help, but the way testing works it's
e.g. not impossible that at some time testing contains a mixture between
two major KDE or two major GNOME releases. This is definitely not a
state you want in a stable release.
> > Your personal prediction is that Debian 3.1 will be released in summer
> > 2004. Unfortunately, this doesn't matter much as long as there's noone
> > who sets definitely the rough dates. Yes, you can't tell the exact
> > release date, but someone has to set the beginning of the freeze early
> > enough (see above) or there will never be a beginning of the freeze
> > since always new software with new problems floods into unstable.
> >
> Freeze early and often? Perhaps it would be worth having overlapping
> freezes, but one testing distribution seems difficult enough. People whine
The problem aren't overlapping freezes.
Today, Debian stable is more than a year old, and the software in Debian
is at about one and a half years old. It's still not clear whether the
freeze for Debian 3.1 will be in 2003, 2004 or 2005.
Ideally, the beginning of the next freeze should be fixed at the time a
new Debian stable is released.
> if you don't include something like gnome, new Xfree86, kde, gcc... Where
> do we make the cuttoff? Well, that's the RM's decision.
When the maintainers know the date of the freeze they have a hint
whether it's better to improve an older upstream version or to throw the
latest upstream beta into unstable.
> > IMHO a Debian 3.1 with an installer that isn't worse than the one in
> > Debian 3.0 is the minimum.
> >
> Mine too although there was much whining about the old installer and
> sarge+1 probably won't be out for a while so others may argue to wait.
>...
Today, one of the biggest problems of Debian is the really outdated
software in Debian.
The woody installer isn't perfect, but it's reasonable working.
A new installer might give some new users.
The current situation with really outdated software is a reason for many
people to switch from Debian to other distributions.
> > If it would take e.g. one year to get $important-nice-feature into the
> > installer there's enough time to release Debian 3.1 and start the freeze
> > for Debian 3.2 short after the release of Debian 3.1 to get this
> > $important-nice-feature into a stable release.
> >
> I don't think it'd be one year, but it may cut into the freeze if
> forgotten and then may delay the freeze. Freezes should be as short as
> possible (imho).
If you look at the last freezes, "as short as possible" is most likely
at about 6 months.
> > If a freeze date would be set e.g. in two months from now I don't expect
> > any unsolvable problems with the software currently in unstable (except
> > perhaps the installer). If the time until the freeze is used for a big
> > decrease in the number of RC bugs things wouldn't look bad for a
> > Debian 3.1 in the first half of 2004. OTOH, I miht be able to fix let's
> > say 100 RC bugs, but without a definitely knowledge about release plans
> > this doesn't help anything.
> >
> I assume you mean the software currently in testing, and I do. I also see
> many more problems with sofware in unstable. RC bugs could be worried
> about in a freeze.
It will take at least one month to get the number of RC bugs down to a
manageable size. IOW, setting a fixed date for the beginning of the
freeze and starting to work hard on all RC bugs at the same time will
shorten the freeze by one month.
>...
> Overall I have to say I also want releases more often, and I bet most
> people do too. I can't say how we can achive this, if you can, please
> polish up a proposal and present it. Keep in mind the concept of "release
> goals", the way things are currently done, the limited manpower available,
> and how we could transition to your proposal (i.e. after sarge is
> released?).
>...
The thoughts I had one and a half years ago are at [1]. These were just
my personal thoughts at that time. Today, I am not as optimistic
regarding the estimated freeze time, with the current number of RC bugs
the fixing should start before the freeze, and some other details might
need changing, but the general thoughts I had haven't changed much.
There is not much transition time, you can start today.
> I've also been thinking about how to make a version of "Debian" that could
> support many individual backports. I haven't presented a proposal on this
> as I haven't had time to sit down and think about potential problems and
> implementation issues.
The work to do something like this right isn't much less than the work
to make a new stable release of Debian.
There are many subtle problems that occur, e.g. an updated libvorbis I
once added to a collection of backport packages I offer [2] caused
breakages for people using a KDE backport.
> Drew Daniels
cu
Adrian
[1] http://www.fs.tum.de/~bunk/Debian/freeze
[2] http://www.fs.tum.de/~bunk/packages
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: