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

Re: wterm in potato

On Sun, Feb 20, 2000 at 05:19:13PM +0100, Josip Rodin wrote:
> On Mon, Feb 21, 2000 at 01:48:30AM +1000, Anthony Towns wrote:
> > > > What's your point? Neither is release critical.
> > > What can I say but: I disagree.
> > You could offer an objective, non-circular rationale for what bugs should
> > be considered release-critical or not.
> FWIW, IMHO "release-critical bug" is a misnomer. There can exist
> release-critical packages, those packages with which we can not really
> release, and bugs against such packages can be marked as release-critical.

Hmmm. It's not so much the *package* that's the problem though, as the
bug itself. I presume, eg, you'd be perfectly happy to release wterm if
its various obnoxious bugs had been removed in time?

I wonder if we should look back at the definition of main from policy:

     In addition, the packages in "main" [...]
        * must not be so buggy that we refuse to support them,

If we're getting to the point where we're saying `foo is a puggy piece of
junk. use bar instead.', even if none of the bugs alone are RC, that could
still reasonably warrant a `package is too buggy' severe-policy-violation
bug. :-/

That's not the case here though, since there's only one relevant bug, which
is either RC or not.

> However, bugs against other packages that aren't release-critical, meaning
> we can remove them and live on without them, can only be described as bugs
> "making the package in question not suitable for release" (or similar).

Yes, I guess so. I just think of it as being critical to the package's
release, rather than the release as a whole, though.

> Anyhow, I don't exactly know how to make `Severity: important' definition
> more concrete/non-vague/whatever.

More *objective*. So that you can say `yes, it definitely satisfies these
properties, anyone can see that without having to discuss it on -devel, so
therefore the bug's important enough that the package should be removed'.

> > You could provide an argument as to why it's better not to provide these
> > packages at all, than to offer them in their existing semi-broken state.
> I doubt this will be taken as a real argument... but anyway... It appears to
> me that there's no point in having semi-broken (well, that might be too
> harsh in the case of wterm) in the archive, when we have them in a working
> state, or when we have other programs of very similar features, also in a
> fully-working state.

This sounds kinda related to one of the positions that only Joel Klecker
had the balls to include in his DPL platform:

   One other problem I want to address is the amount of useless packages
   in Debian, our goal should not be to package every piece of free
   software in the world no matter how useless. I'm not sure of the best
   way to approach this problem or how to solve it, but it will be
   something I'll investigate.

ie, since wterm has both some fairly lame bugs, and doesn't really do
anything special, and since there are other packages without the lame
bugs, wterm is therefore a `useless package' (to use the technical term)
and shouldn't be included in Debian.

This does, actually have a certain internal logic to it.

Which is really quite annoying when you're trying to disagree with it.


Note that this is using a different criterion for rejecting a package
than just the traditional `it has a security hole, don't install it', or
`it'll delete your files, don't install it'. This is more `no, there're
much better programs, trust us. use one of them instead.', which we don't
generally do in Debian. Yet, at least.


Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds

Attachment: pgpp0N1Fz7sKC.pgp
Description: PGP signature

Reply to: