Re: About the Hamm Freeze
> > > > I'll be trying
> > > > to limit changes in Hamm to bug-fixes only. All critical, grave, and
> > > > important bugs _must_ be marked as done before a packages will be allowed
> > > > into Hamm.
> > >
> > > 'bug-fixes only'... Is that 'registered Debian bugs' or any bug?
> > > I'm both the author and maintainer of tcpquota and xadmin, and I are fixing
> > > bugs in tcpquota (oki, so I add features to, that's where the bugs are comming
> > > from... :), would it be ok to upload such new versions?
> >
> > no ;-) - no new features, please. Debian 2.0 should be as stable as
> > possible. New features should go into unstable. Any user who is
> > interested into these new features can install the new package.
>
> 'no new features'... That would be a little problematic, since one way
> to fix a bug (here: not a Debian bug) is to rethink the problem and rewrite
> the program a little...
Yes, but at that point you have to make a choice. Do you stick with the
known bug or the unknown bugs created by the new feature. While it's easy
to fixate on the known and obvious, experience says that it's usually better
than what will crop up in the unknown (and largely untested).
> What we are talking about here is bug fixes, which just happens to have new
> features to...
>
> Still not okay? (I'm not trying to be difficult here, I just want to know
> what the rules are...)
In general, correct. New features, whatever the reason, are undesireable.
Brian
( bcwhite@verisim.com )
-------------------------------------------------------------------------------
measure with micrometer, mark with chalk, cut with axe, hope like hell
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: