On Mon, Sep 06, 2004 at 11:23:33PM +0200, Goswin von Brederlow wrote: > Steve Langasek <vorlon@debian.org> writes: > >> - He doesn't need to know the Social Contract or DFSG. > > I think this claim epitomizes the disagreement between those who think > > buildd admins should be DDs, and those who think it doesn't matter. The > > Social Contract is the core expression of Debian's value. What message > > does it send if we don't expect people responsible for core parts of our > > infrastructure to uphold these values? Or, what message does it send if > > our ports can't be sustained by people who are committed to these > > values? > The buildd admin must be a DD since he is maintaining the software > (needs the packaging skills) and uploads packages (needs a gpg key to > sign). > IMHO the question is: Does the hoster need to be a DD? Would you > require IBM to sign the SC before they can offer Debian an S390 to run > a buildd on? Does Ingo haveto become a DD just because he is a trusted > (by other DDs) individuum instead of a big scary unknown cooperation? > Think about it from that side for a moment. I'm not in a position to answer that question for the project; there are others involved in buildd maintenance that have surely put a lot more thought into these questions than I have. The general difference I see between IBM and Ingo, though, is that IBM *as an organization* wouldn't be administering the machine for us and wouldn't have root access. Rather, the terms of a hosting agreement with IBM would probably require them to *not* touch the system. If there were a local admin with root access, he might be expected to be a DD. > >> All a buildd host admin needs is trust from Debian not to screw Debian. > > Part of "trusting" people is trusting that they'll act in the interests > > of the Debian community, which means agreeing to the SC. > Again, does IBM agree with the SC? Does HP? Does IBM have root access to the buildd? Does HP? > IMHO it is enough to not object to the SC which can be a different > thing. The buildd hoster doesn't act in the interests of the Debian > community since he does no work at all (apart from keeping the > _hardware_ running). We were not talking about people whose involvement was limited to *hardware*. > > - The most recent blocking issue on arm is a Qt FTBFS, which could > > hardly be addressed by adding buildds, so taking credit for other > > architectures not being in the same state is inaccurate. > So you are saying that the ~800 packages backlog (counting needs-build > and build but unhandled) on arm was all caused by one single package? The backlog I see consists of less than 200 packages in needs-build. "Built but unhandled" is hardly solvable by adding hardware, is it? > That adding a second build wouldn't help process those packages faster > once the Qt FTBFS is(was) fixed? Did you read something I wrote which said that? > Alpha touched one of the main problems with the official buildds. If > it takes 3 weeks to get the OK and wanna-build access from James just > to run a buildd for 4 days while the normal one gets fixed that makes > it pointless. > It would be nice to have some preapproved people that can jump in on a > moments notice and setup a buildd for a few days. A fast acting > disater relieve team. And by that I mean are allowed to jump in. No, it would be nice to have n+1 redundancy for our buildd hardware (in the form of excess buildd capacity that can keep up with the package load in spite of any single hardware failure), so that people don't *need* to "jump in on a moment's notice". If having people "jump in" is the best we can do, then it's the best we can do, but I still don't consider it "nice". -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature