Re: Debian's problems
Aaron Van Couwenberghe wrote:
> On Sun, Sep 12, 1999 at 11:00:19PM -0400, Joe Drew wrote:
> > Limits can be brought about by doing one thing, that everyone
> > will bitch and moan about: /not/ forking off into unstable once
> > potato freezes, and having every single maintainer of every single
> > critical bug incessantly tortured about it until it is fixed, if
> > it's possible to be fixed. Believe me, frozen will be finished
> > quickly.
>
> Neglecting to open up unstable for development after a freeze will *not*
> speed up release cycles. Think about it. A very large group of debian's
> developers are highly specialized. If you take away their work, many of them
> would sit idle until unstable *did* finally get rolling.
We don't need to take away their work etc. However, continueing to do
major changes at a late time will postpone the freeze and therefore
the release as well.
If major changes are to be prepared, we will need to open up an
unstable-staging aerea to compensate this. They must not badly
influence the unstable/frozen branch. From the staging aera it
will be moved to unstable after the release (or after it was
frozen and a new unstable has been created.)
> It's not like we can dictate where people will spend their time in debian.
That's correct. However, a handful of people needs to spend their
time on management or we will die due to no leadership. I'm not
saying that leading such a crowd of hackers is easy, but it needs
to be done.
> If you take away someone's freedom, he will most likely just sit on his
> hands.
Yes. Therefore we open staging areas for that, we encourage people to
work on small special tasks that will help implementing the big goal.
> So if Joe developer usually takes 3 months to get a working, finished
> package of his extremely complex package 'foo' perfected, delaying
> unstable's appearance for 2 months will just change joe's time to 3+2 = 5
> months.
If the package is standalone, it's fine to get into unstable/frozen. If
it affects like a dozen others, like new kernel, new perl, new X etc.
a decision needs to be made if this package may go into unstable/frozen
at this late time. This would require either a black/white scheme or
somebody clueful who can forsee what will happen.
Regards,
Joey
--
GNU GPL: "The source will be with you... always."
Please always Cc to me when replying to me on the lists.
Reply to: