Re: Partial freeze?
I agree, though "boot floppies" should NOT fall under the exact same rules. The
reason for this is that, while the contents of the floppies may change, the
installers will generally be where the most work is needed. Once the installer
is working, it's a matter of how to fit the rest of the information on the
disks. If libc changes, it should NOT necessarily affect how the installer
runs. From what I've heard, we can already move to the boot floppy work
beginning well before freeze, with the images being changed at regular
intervals to handle changes.
Dave Bristel
By use, everything is dependant on the boot floppies for installation, yet once
installed, nothing depends on them.
On Mon, 8 Nov 1999, Mike Goldman wrote:
> Date: Mon, 08 Nov 1999 22:15:49 +0000
> From: Mike Goldman <whig@by.net>
> To: Chris Leishman <masklin@debian.org>, debian-devel@lists.debian.org
> Subject: Re: Partial freeze?
> Resent-Date: 8 Nov 1999 22:15:56 -0000
> Resent-From: debian-devel@lists.debian.org
> Resent-cc: recipient list not shown: ;
>
> Rereading what I wrote, I realize that I've contradicted myself from previous posts.
> I don't think it is fair to maintainers of release critical packages, which have no
> >wishlist bugs filed against them, to be precluded from uploading new packages.
> However, the current state of these packages should be frozen, now.
>
> I understand, some packages are not yet "feature-complete" -- i.e., boot-floppies.
> These should be left unfrozen until they are ready, and then frozen. As soon as all
> release critical packages are frozen, we should freeze everything else.
>
> Mike Goldman wrote:
>
> > I'd be in favor of doing this *now*, but I'm not sure if it can be enforced with
> > current tools. If dinstall can be configured to selectively hold updates to
> > certain packages, pending ftpmaster approval, while letting through others, let's
> > do it. Even if it cannot be enforced, I think that maintainers of release
> > critical packages should be asked to immediately refrain from any updates which do
> > not fix important bugs, and nothing else.
> >
> > The alternative scenario, which is just absurd, is to keep our fingers crossed
> > until the next "scheduled" freeze, hoping that we can actually do it, but
> > realizing that it may be delayed again, and again.
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: