Re: architecture-specific release criteria - requalification needed
Steve Langasek <vorlon@debian.org> writes:
> On Thu, Sep 22, 2005 at 02:15:57PM +0200, Ingo Juergensmann wrote:
>> > graphics/gem_1:0.90.0-17: Dep-Wait by buildd_m68k-kiivi [optional:out-of-date]
>> > Dependencies: libjack0.80.0-0 (>= 0.99.0)
>> > Previous state was Building until 2005 Aug 10 08:44:01
>> > This is a sampling of screwy dep-waits I was able to find by glancing
>> > through the buildd.debian.org webpages, and excludes those that I've already
>> > specifically asked the m68k porters to remove in the recent past because
>> > they were holding up transitions.
>
>> So, what is better: to set a dep-wait and maybe do something wrong or
>> setting no dep-wait at all and let the package in Building state for weeks?
>
> Which is more likely to get attention from a porter who happens to be in a
> position to correctly diagnose the build failure: a package which is listed
> as "Building" with a failure build log to be looked at, or a package which
> has already had its build log processed and marked as Dep-Wait?
I think with simple Dep-Waits set to Dep-Wait and clear FTBFS set to
failed the remaining mystery failures (left in building) get much more
attention as well as the FTBFS do.
With everything just left in building (as other archs have) the
intresting cases drown in the trivial ones and nobody cares to even
look anymore.
Maybe W-B could send out a weekly mail listing all Dep-Waits older
than 2 weeks or something to make wrong entries more visible.
Or buildd.net could add "stale" lists for each w-b state listing only
packages that remained in each state for more than 2 weeks.
Ingo: How about that?
> Maybe the issue is that neither gets much attention; maybe that's why wrong
> Dep-Waits happen in the first place. ;) Then again, maybe the m68k buildd
> maintainers do have time to periodically review stale dep-waits that they've
> set, to check them for correctness; that would be a pleasant surprise.
> Either way, it's only an issue for *me* when I notice it before someone else
> does. :) And I know it takes me longer to notice a wrong dep-wait than it
> takes me to notice a maybe-failed package that could be requeued.
Practice, practice. :)
> Anyway, this isn't end-of-the-world stuff, it's just a simple observation
> about how having more people involved does bring a corresponding cost of
> team coordination.
MfG
Goswin
Reply to: