Re: removal of vips and nip2 from testing
Hi,
* Jay Berkenbilt (qjb@debian.org) [080407 17:37]:
> Vips and nip2 were removed from testing. This was in the automated
> email:
>
> > Previous version: 7.12.5-3
> > Current version: (not in testing)
> > Hint: <http://ftp-master.debian.org/testing/hints/aba>
> > #20080329
> > # vips FTBFS. #474405
>
> and looking at the hints file, it appears that the script accurately
> captured the reason.
actually, I massaged the hints file after the fact to give it at least a
bit of reasoning more than "needed it for openexr" (though perhaps not
optimal described).
> The FTBFS bug report was only a day old when this happened, and I
> uploaded a fix for it the same day that I received the bug report. It
> seems a bit extreme to me to have these packages removed from testing
> for a FTBFS bug that was just a day old. Is this becoming a new
> practice, or were there extenuating circumstances such as vips being
> involved in an openexr transition and someone looking for blockers,
> seeing the FTBFS bug, and taking quick action without looking at the
> circumstances? Or was this really the best thing to do to get a
> transition through in any case?
The openexr transition was pending for quite a long time, and we needed
to finally get it through before it gets even larger, and so that we can
start now the next transitions. This was definitly exceptional, but
- well, exceptions happen. As this was exceptional, I can offer you my
full assistence to get the packages back into testing (same for the
other packages removed at that occasion). (What was especially bad with
this transition that in this case we needed to force-hint it through
because as soon as openexr was available to our migration scripts, run
time exploded to more than 25 hours - for this reason we mostly blocked
it by hand. You can see the reminders of the mess in my hints file.)
One thing that I do (and still are doing) is looking at all removed
packages, and see what needs to be done to get them back in again. For
vips, I now set the maximum needed age to two days (and it's already
picked up by all buildds, so no need to do something there), so the
removal should only be for 1-3 days.
For the other packages, lua-zip waits for an build of zziplib and also 2
days of aging. Lam also needs aging for two days and should get back in
by itself. I'll follow this up.
> I fully understand that people who make these decisions have a lot of
> work to do and may occasionally make errors in judgment, so if that's
> what this turns out to be, I'm not criticizing anyone. I just want to
> understand whether immediate removal from testing upon reporting of an
> FTBFS bug is something I can expect in the future or whether there's
> anything I could have done to prevent this from having happened.
You can expect that to happen in total over all packages about 1-4
occasions per year, hitting 1 to 10 packages. Under normal
circumstances, packages FTBFS might trigger removal if they're left
alone for 14 or more days.
> As a
> responsible maintainer who takes care of problems quickly, I'll admit
> to being somewhat annoyed by this action.
I hope it might be some comfort that I connect your name in my head with
"good maintainer" and "acts quickly". It was just unhappy this time when
this bug was noticed that this was mostly the last blocker to this large
transition. I need to admit I wasn't happy adding the removal hints, but
I considered that at the time the "less bad" action.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Reply to: