On Mon, 2004-06-07 at 19:41 +0200, Goswin von Brederlow wrote: > Scott James Remnant <scott@netsplit.com> writes: > > On Mon, 2004-06-07 at 01:55 +0200, Adrian Bunk wrote: > > > >> 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. > A "broken toolchain" would be one which breaks *everything* -- not one that breaks one or two packages. > > 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. > It's still the case currently though. > > 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. > I don't, I just change it. I get angry when people wander through my bug list randomly bumping severities without even checking with me. > > 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? > No, it's not a bug, it's just a stupid thing to do for any of the autotools. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Attachment:
signature.asc
Description: This is a digitally signed message part