[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]


Ben Collins wrote:

> But, I have had my rants about this in the past, and it seems people are
> more concerned with having new and exciting packages, than making
> frozen a complete and bug free release (just think what would happen if at
> freeze, every maintainer fixed all the bugs in their own packages, barring
> wishlist items, wouldn't that be neat). The ones who didn't have bugs
> could a) help with documentation or boot disks if they desired, or b)
> start working locally with new packages and new versions, taking the time
> to test new things, or c) do nothing and relish the bug freeness of their
> packages, and enjoy the time off they deserve.

Well, I agree with the first part of this -- during the freeze, maintainers
with release critical bugs should not be allowed to upload new packages to
unstable.  If you want to extend that to any >wishlist bugs, I'm open to
discussion on this as well.  I certainly don't see why a maintainer with no
bugs should be forced to do A, B or C.  Sure, it's great if maintainers with
the time and expertise could work on boot disks, or help to fix bugs in other
packages, or if they have good writing skills, to write documentation, etc.
And hopefully some will do so, taking time off from their ordinary package
maintenance during the freeze.  But we shouldn't force volunteers to do what
they don't want to do, when they've already done what they agreed to do.  Keep
in mind that picking up another package is not cost-free, it requires a certain
amount of time just to get up to speed on what the package is supposed to be
doing, and how it is supposed to be built, etc., before one can even start to
figure out why it isn't doing what it should be.

Do we need to make a policy proposal of the first part?

In any case, and the most important thing of all from my perspective, is that
we should be freezing MUCH more often, and releasing SEVERAL times a year.  If
there are reasons why it has been impractical to do this in the past, we need
to identify and remove these obstacles.  Slink was obsolete as soon as it was
released, and now more than a year later, we still have no stable update to
offer.  Sure, I run unstable on my home machines, but I'd just as soon run
stable on my servers, and I can't do it in many cases without sacrificing a lot
of functionality.  This means I have to spend lots of extra time and effort
checking to make sure things are reasonably safe, and still have a lot of
concern about unknown problems.  If stable lagged unstable by three or even six
months, it wouldn't be a terrible thing, but this is ridiculous!

Reply to: