Re: potato late, goals for woody (IMHO)
On 01-May-00, 14:04 (CDT), Hartmut Koptein <koptein@naffel.de> wrote:
> Correct, but if we have it ready after one month of work, we must wait
> 14 months to release it. Ok, this is not 100% fully true, but i hope you
> get the idea.
I understand your argument now, I just don't agree with it. Few[1] works
on the boot floppies until the freeze, anyway.
> > > can fix faster bad setups (boot-floppies, x11, usb, firewire,
> > > keyboards, languages, ...)
> >
> > That's a matter of doing update releases on the stable dist, which we
> > are now doing.
>
> Will we have xfree4.0 for slink?
That's not a "bad setup", by my interpetation. (I was thinking of
defects in the maintainer scripts, etc.) If you're talking about support
for newer hardware, then I agree, that's one of the few arguments for
faster releases that is valid. OTOH, it *could* mostly be dealt with by
newer kernels/boot floppies. (e.g. newer video cards *are* supported by
Xfree86 (SVGA), just not 3D-accelerated.)
> > > * we see a light at the end of the tunnel, have not so big goals,
> > > better quality managment,
> >
> > Why better QM?
>
> 1 year cycle: 1000 or all packages must be checked
> 3-4 months : 100 (+/-) must be checked
Strongly disagree. If you don't test all the packages, you don't have
QM. If you upgrade the C library, you have to test all the packages that
use it, whether or not they were upgraded too.
> No; we had no development stop after three months in the past. So everyone
> ignore it and all maintainers think year-wise and not month-wise. The
> delay comes then automatic.
We had no development stop after three months because little or nothing
had been done, because no goals had been set.
> Right. Do you upload to woody (only woody i mean)? Why, if so? Why
> not helping in quality control and documentation?
No, I don't upload to (only) unstable until after the release of frozen.
Others disagree.
> > > * easier for test-utilities
> >
> > Why?
>
> Because we have less packages to test.
See above remarks on QM.
> > > * we must not wait for the next version of gcc, libc, kernel, x11,
> > > mesa, ...
> >
> > Were not waiting for them (or maybe I don't understand what you're
> > saying).
>
> kernel-image-2.2.15 is such an example, xfree-3.3.3 another one in the past.
>
> > > * hopefully less RCB's
> >
> > Why?
>
> 50 or 100 new(er) packages have less RCBs then 1000.
Most of those new packages can be pulled from the release. RCBs on
critical packages like gcc, X, etc. are going to occur at a more or less
constant rate.
Steve
[1] I'm not slamming the boot-floppies team. I know some of you probably
*do* work on it before the freeze. I'd guess you don't much (any?)
testing help before the freeze, though (me included).
Reply to: