Re: debian 2.1r3 needed and release team coordination
On Sun, 4 Apr 1999, Richard Braakman wrote:
> Hmm, 2.2.1 or 2.2.5, it was "use at your own risk". If 2.2.1 has known
> problems then it would be more consistent with our policy for stable
> to simply remove it.
I'l personally testify to the stability of 2.2.1, excepting 'strange'
(read; not 100% supported) soundcards, which have very infrequent DRQ
problems. Almost non-existant.
However, I never got it to stay up over a week. I have a 2.2.5 box at
work, though, that's going on, jeez, I dunno.. couple days. No problems.
Never had an issue with it yet.
> Okay, both of these points are about grave bugs. I'm okay with the
> idea of relaxing "security bugs only" to include grave bugs, but then
> we really need a more solid structure for such changes. That means
> explicit testing, and the packages should be built for all architectures
> that we support. We need this for security updates as well. Can
> it be done?
I'll have to agree. With 'Mission Critical' (bugs that prevent booting,
bugs that affect common hardware, etc.) bugs, NMU's should definitely be
allowed for quick and proper fixing of problems like those.
> I don't think this is a good idea. As you said, it's something for
> potato. We should start work on potato bootfloppies; let's not
> involve the slink bootfloppies in this work.
*nods* I agree. Keep them seperate. Once stable in potato, it might be an
idea to put them in 2.1r4 or later. But not yet.
> Point releases for slink are already being made for security updates.
> I think we have to consider other changes on their individual merits.
*nods* I think priorities should lay first on the boot floppy problems
(AIC-7xxx and what have you), and utterly broken and/or insecure packages.
Everything else, maybe. Maybe not. It depends on the severity of the
problem, I suppose.
-prj
Reply to: