On Mon, Dec 15, 2003 at 06:40:56PM +0100, Sven Luther wrote: > > > > > advi: Maintainer won't fix the RC bug until he fixes "other" > > > > > problems, > > > > > which he hasn't gotten around to. Packages which FTBFS should not be > > > > > in > > > > > sarge. Accordingly, remove it until the maintainer gets around to > > > > > fixing > > > > > his bugs. (or, yell at the maintainer with authority ;-)
> > > > It's such a simple fix that it's only one-line and I don't know if it's > > > > really > > > > worth it, but if it's going to be removed I've got packages that > > > > require advi. > > > Why should it be removed ? There is really no reason for it, we are not > > > near the release in any stretch of the imagination, we are at least > > > month from being ready. > > Is it currently releasable? If not, then there's no reason to keep it > > in testing, is there? > Yes it is, there is nothing wrong with the package, it is statically > linked to ocaml, so didn't need to get rebuild for ocaml 3.07, which is > why i didn't upload it. "Not buildable" -> "not releasable." This is not a new concept. There's more at issue here than whether you as the maintainer believe it would be trivial to fix this bug when you got around to it; we have to support things like security updates, which demand packages which conform to the interfaces published in Policy. Now, it could have been that this FTBFS bug really only applied to sid, and not to sarge (because the build-dependencies were still available in sarge); but if that were the case, I would have expected you to tag this bug "sid" instead of developing a persecution complex because people expect buggy packages to be fixed or removed. (And I've just confirmed that the build-dependency is also unsatisfiable in testing.) > > Would you really prefer that packages only be removed from testing at > > the very last minute, leaving maintainers no time to get a fixed version > > back in? > Heck, if the ftp-masters had time to loose, then why not, but this not > being the case, there are tons of more important things to fix than > this, and i am sure that if i ask for the removal of the 2.4.20 and > 2.4.21 powerpc kernel today, this will not happen before weeks, while > those are plaged with a local root exploit. Indeed i will do that this > evening. Removing packages from testing is the domain of the release manager; removing packages from unstable (and NEW queue processing) is the domain of the ftp-master team at large. Unless you mean for the release manager to prioritize the general queue management work above the specific release management work, I don't see how the two are much related. All the moreso when you consider that this request only showed up on a public mailing list because the person proposing the removal is not an ftp-master. > > > Time would be much better spent fixing one of the billion other RC bugs > > > around, instead of this minor bug. > > It may be trivial to /fix/, but a FTBFS is not "minor". > dpkg-buildpackage -d fixes it. It is not really a FTBFS, just a broken > build dependency. Anyway, i uploaded a fixed package now, including > dpatchification, so you will all stop bothering me about this, and let > me time to do real bug fixing. It is also in the ocaml SVN repository on > alioth now, so anyone feeling like helping out with the other stuff can > give a hand there. Your misrepresentation of "FTBFS" here is truly mind-boggling. RC bugs do not become less important because they're easy (for the maintainer) to fix; if anything, they become MORE important, because this demonstrates all the more that a package isn't receiving the minimal level of attention required from its maintainer. If you're really this upset about being asked to not let an RC bug languish in the BTS for over a month, perhaps you should consider putting this package up for adoption -- or at least asking for help with it? You clearly have other Debian tasks you're working on which you assign a higher priority to. This is no fault, but it's still important that RC bugs be taken care of, even if the way to do that is to cede responsibility for the package. -- Steve Langasek postmodern programmer
pgpc9Uv4EX7IT.pgp
Description: PGP signature
