Re: libc6_2.0.7r-3 considered harmful
> On Mon, Jul 06, 1998 at 08:19:17PM +0100, Philip Hands wrote:
> > > Philip Hands <phil@hands.com> writes:
> > > > How many people have been bitten by this since the bug was found ?
> > > > We should have been able to prevent this damage in some way --- even
> > > > if it means having no libc6 available for a couple of days, this
> > > > seems preferable to breaking people's systems when we could avoid
> > > > it.
> > >
> > > Well, in my mind, the real way to fix this sort of thing is by
> > > reworking our release engineering process. No packages should
> > > propogated into stable (or beta) unless it has been tested by X number
> > > of people, where X > 2. Testers are just users or developers who
> > > install the package on a supported platform (i.e., stable or frozen)
> > > and ensure that the pkg functions. Ideally we have regression testing
> > > for *everything*, but I think that's a pipe dream.
> >
> > This would certainly limit the number of times this sort of thing could
> > happen, but it will still happen.
> >
> > We need a way of dealing with it when it does.
>
> save the last n *diff.gz on master.
> with this files alle developers can make a new 'old' package and upload
> a NMU to master (a old Version).
Not good enough I'm afraid.
What if we've changed compilers in the interim, and the old source no longer
compiles ? (there are loads of other things that might mean that the package
you are reverting to is not actually the same as it was the last time around).
Also, in the case of libc6 I would certainly not want to be the one to take
responsibility for getting an emergency NMU built, so reverting to the
previous actual binaries seems like the only option.
I don't think we necessarily need to keep copies of all old packages to do
this. The libc6_2.0.7r-2 binaries were all available despite the fact that we
hadn't made any attempt the save them in a controlled manner.
The thing that was missing was a mechanism for making the decision to
reinstate them.
Cheers, Phil.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: