Re: Formal objection: Changing how the testing of potato works would invalidate the whole test. So please don't change it.
Richard Braakman <email@example.com> writes:
> We'll also throw away the boot-floppies we have now. So I'll pose this
> to the people working on them: What do you prefer? Go with 2.2.13 for
> a two-week test, or stop this cycle and prepare new ones about a week
> from now?
I would just continue with the current cycle, but knowing we'll have
to do another cycle.
I say this because i386 (at least) has to go from 2.2.15pre20 to
2.2.15 (release) and generally that process involves at least 3 people
and takes around a week, so I just don't know if a boot-floppies can
be ready with this kernel in time.
This is on the assumption that the next release cycle should be a
release candidate (and I think releasing with a pre-release kernel and
adaptec problems on i386 isn't acceptable).
My argument boils down to the fact that it will take a week or two to
start the next cycle anyhow, so why not just proceed with this one as
plan. Any of the arguments I've seen to abort the current cycle seem
pretty weak to me.
The next cycle should include the following packages for
tasksel 1.0-9 (or better) (i18n)
kernel-image-2.2.15-2 (adaptec fixes, Bug#63946)
Uh, that's it. I guess the new apt looks ok too -- seems like that's
needed for CD-ROM ?
Regarding the handling of this whole thing, I think we should treat
potato rather like we treat the updates to stable. To wit, perhaps we
could distinguish between Incoming and 'proposed-frozen-updates' ? I
dunno, just a thought. That would those who care (boot-floppies, cd
team) get a jump on the next cycle, with a reasonable expectation of
the packages that will be in it.
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>