Re: Processed: breaking the build of other packages is RC
Scott James Remnant <scott@netsplit.com> writes:
> On Mon, 2004-06-07 at 01:55 +0200, Adrian Bunk wrote:
>
>> On Sun, Jun 06, 2004 at 04:19:41AM +0100, Scott James Remnant wrote:
>> > No... making *unrelated* software is release critical, and warrants a
>> > "critical" severity instead of "grave". grave is defined as:
>> >
>> > makes the package in question unusable or mostly so, or causes
>> > data loss, or introduces a security hole allowing access to the
>> > accounts of users who use the package.
>> >
>> > none of which describe this bug. "important" is the appropriate
>> > severity (in fact, it could be argued that "normal" is the appropriate
>> > severity, but I personally like to keep libtool-caused FTBFS bugs at
>> > important until I've thoroughly checked them myself).
>>
>> If a FTBFS in a package is RC, it would be very strange if an update of
>> build dependency package that causes a buld failure wasn't RC...
>>
> This seems logical, except by inference you've just made almost every
> bug in a tool-chain or build-system package Release Critical, which
> would make the BTS vastly non-useful for those of us who maintain such
> packages.
On the other hand you wouldn't want a broken toolchain to enter sarge
and an RC bug would do that.
> When filing bugs, there seems to be a tendency for some people to shove
> the severity as high as it will go without toppling over. This is
> usually counter-productive -- severities should be considered relative
> to the package you are filing against and if in doubt "normal".
>
> This doesn't mean you shove all (eg. gcc) bugs in as "grave" or
> "critical", it means you use "normal" or perhaps "important" in cases
> where something that worked before has stopped working. Only use higher
> severities such as "grave" where the bug is causing most of the archive
> to not build, or something.
>
>
> As for FTBFS themselves, you appear to be misunderstanding *why* they're
> filed at the level they are filed at. Being unable to even *build* a
> package falls under "makes the package in question unusable or mostly
> so". We only ever release packages with the same version on all
> architectures[0], so having the latest unstable release simply
> unbuildable does make that a Release Critical issue *for that package*.
>
> We don't, however, take build dependencies into account when preparing a
> release. Britney doesn't guarantee that testing is buildable, a package
> can be placed in stable without its necessary build-depends.
Which is a bug and not a wanted feature. People are working on that so
in the future Build-Depends might be checked utomatically for sarge.
> So this makes the issue of how to deal with a package whose FTFBS is
> caused by a build-depend a slightly interesting one. In the end, one
> can always use the previous version of the build-depend and upload with
> that, close the FTBFS bug and open a new one or reassign with a
> different title and severity against the build-depend package.
>
> As I've stated, my personal preference for "it breaks one or two
> packages that work with the older version" is the 'important' severity.
If it just breaks one or two sources it would just be buggy. If it
breaks all sources it would be unusable. So yeah, important or just
normal if its just special sources that break. But don't get angry
about people that leave the severity alone when reassigning a FTBFS.
> This "friendly" approach doesn't even apply for Libtool though, it
> should never be a build-depend -- the necessary files should be included
> in the package. All the package has to do is roll back, upload a new
> version and fix the bug. A separate bug can be opened at the lower
> severity against Libtool.
Uh oh. Do you know how many packages Build-Depend on libtool or forget
to Build-Conflict with it (i.e. use it when its available)?
Are you as libtool maintainer saying we should file a bug about any
source that uses libtool during build?
MfG
Goswin
Reply to: