On Tue, Dec 06, 2005 at 11:03:40AM +0100, Thiemo Seufer wrote: > Steve Langasek wrote: > [snip] > > > > So those should get added to P-a-s instead. > > > Well, but that'd be something for the buildd-admin to collect. > > > (Or maintainers of the packages, but that doesn't seem to fashionable > > > nowadays...) > > Um... no. This is *porter* work; one does not have to be a buildd admin to > > analyze a build failure to see whether the package belongs in P-a-s, and > > there's no reason that the buildd admins alone should bear the > > responsibility for figuring out whether a permanent build failure should be > > fixed or ignored. (Maintainers probably need to be involved in this > > process, but usually maintainers don't have the requisite knowledge about > > all our ports to make informed decisions on their own.) > FWIW, I started to send mips patches for P-a-s, following the procedure > outlined at the top of this file. There was neither a response nor any > other discernable action. > > Saying "that's the buildd admin's job" about tasks that don't *need* to be > > done by the buildd admin is a pretty effective way of encouraging the > > problems that the Vancouver proposal sought to address, where two or three > > people end up carrying all the ports, and all their time is eaten up by > > maintaining the buildds and giving back failed packages with no time for > > following through on the permanent failures (which, even though they > > sometimes represent a minority of Maybe-Failed packages usually account for > > a majority of the actual work needing done). > A while later, and rather by accident, Ryan Murray told me on IRC > (paraphrased) "Of course they were ignored, you aren't a buildd admin. > Send them to me." So I did. Ryan acknowledged to have received them with > (again paraphrased) "Well, it's not so urgent." This was about 6 weeks ago. Well, a few comments: - Ryan is not himself one of the people listed as contacts for P-a-s; he may consider it best to send such changes through the buildd admins, but that doesn't mean that's the only way for them to be accepted. - I know for a fact that changes *have* been accepted from non-buildd folks (myself included). - Even without it being a policy, there's some truth to the idea that changes are going to be accepted more readily from folks that are trusted to get it right, because there's less need for review on the part of the P-a-s maintainers. And buildd folks are going to be at the top of the list wrt knowing what's going on with P-a-s; but feeding the changes to a very busy buildd admin instead of a very busy P-a-s maintainer isn't an obvious win. :) Much better that the porters show themselves to be competent wrt P-a-s, so that over time their changes *will* be trusted without lengthy delays while someone finds time to review them. - He's right, it's not urgent. :) So don't sweat the delays too much. - I just checked with Adam Conrad on IRC, who was recently added as a third P-a-s maintainer because three busy contacts are better than two. He asks that you please forward your changes to him. > > > >>weechat: don't know, error on dh-strip on 5 archs, no bug filed > > > >>That's 2 out of 7 which need actual debugging, both not arm-specific. > > > > And only 1/7 where some action of the buildd maintainer is needed > > > > at this time to get something build. > > > The dep-wait is well inside the "some action of the buildd maintainer is > > > needed". The needed P-a-s entries could be handeled centrally if the > > > problem description is "pile of maybe-failed packages". > > Wonderful. Nice to see that you think P-a-s entries are somebody else's > > problem that should be "handled centrally". > It appears to be the idea of the people with write access to P-a-s. Oh, well... appearances *can* be deceiving. Never attribute to malice that which can be adequately explained by people wearing a whole buncha hats. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature