On Sat, May 27, 2000 at 08:07:00PM -0400, Branden Robinson wrote:
> > ] Because it's too late. They've already been renamed. If I had
> > ] appreciated the difficulties this would have caused me [...]
> I don't see how this contradicts what I said.
It wasn't particularly meant to: it was meant to support what I said. And
since we seem to have been talking at cross purposes...
> > What I meant by the above was that unforseen problems can and do fuck
> > things up royally. Examples from this freeze seem to be xchat and epic4
> > which had a run of new upstream versions that surely couldn't have caused
> > problems, that did, repeatedly.
> Then the maintainers should have been taken to task for breaking the rules.
Not really: as I understand it, they moved onto new upstream versions in
order to fix existing release-critical bugs, and ended up introducing
new ones, for which there were bugfix-only upstream updates that just
introduced more bugs.
> I still don't think the Great X Reorganization is a good example of a
> maintainer violating the freeze policy.
Well, no, obviously not, since we weren't in the freeze at the time;
but that's not really what I'm trying to get at. [0]
It's basically more an issue of lots of bits of Debian being complicated
enough that apparently sensible fixes are going to balloon into huge
messes every now and then. The only real way of avoiding these sorts
of things is just to stop making *any* non-essential changes [2], and,
considering we're already four months into a freeze, now seems like as
good a time as any to start taking that fairly seriously.
For reference, I'd hope testing will mitigate some of this by giving
us a couple of weeks (or at least a couple of days [3]) to test fixes
before we actually have to commit to them.
Cheers,
aj
[0] Violating freeze policy isn't the sin, introducing bugs is. This is
similar to the apocryphal Rule #1 of NMUs [1]. Well, IMAO, anyway.
[1] viz, "Get it right. All else is secondary."
[2] Making ssh standard isn't particularly essential, fixing security
issues with X is, eg. Releasing without one done is a pity, maybe,
but no big deal, releasing without the other is a problem.
[3] Packages added to testing are prioritized based on the urgency
specified in the changelog: low takes at least 14 days, medium 7
days, and high 3 days. Packages that accrete RC bugs in that time
obviously don't get added.
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpQ5xmzquknm.pgp
Description: PGP signature