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

Re: Bug#219545: Proposed packages to remove from testing

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

Attachment: pgp1Xc4TJPvBX.pgp
Description: PGP signature

Reply to: