On Wed, Dec 07, 2005 at 04:48:24PM -0600, Bill Allombert wrote: > On Tue, Dec 06, 2005 at 01:14:00AM -0800, Steve Langasek wrote: > > 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). > This go against the two basic rules for a volunteer organisation. > 1) Volunteers doing the job should be people interested in doing it. > 2) Responsibility should go to people that are going to do the job. > Which translates here to: > 1) Buildd admin should be people interested in supporting the port. > 2) People that are going to support the port must get the responsibility. Which is great as a statement of principle, but it doesn't seem to offer much as a practical recommendation; you don't get to be a buildd maintainer by telling the current folks "you aren't taking the right amount of pleasure in this -- better let me do it", you get there by working with the current folks and building a relationship with them and showing that you know what you're doing. Sorry, with a project that's a thousand strong, if they *do* care about the task, not too many people are going to turn it over to someone they don't know without first assuring themselves that they can handle it; and note that I never suggested the current buildd maintainers don't *care* about the ports they're helping with, they just don't have unlimited amounts of time to spend on single-handedly ensuring that ports keep up. BTW, I have no reason to believe that buildd maintenance in general is any more exciting or intrinsically rewarding than filing bugs on failed packages (and providing fixes for the same); so if people are going to balk at the latter task even though this is an area of porting that definitely (in some cases desperately) needs attention, what reason is there to think they're well-suited to being buildd maintainers either? > Making "buildd admin" a purely administrative task while porters are > not even trusted to do a binary upload is not going to work because you > will never find volunteers accepting to work under theses terms. It seems like you're assuming that "buildd admins" and "porters" are two non-overlapping sets. On 6 of 11 architectures, at least one buildd admin is also a porter for that arch under the release requalification guidelines; on 7 of 11 architectures, at least one of the porters has wanna-build access for that arch. So it's certainly not the case that no porters are trusted to do binNMUs. If what you're arguing is that *all* porters should have wanna-build/buildd access (which is the best way to do binNMUs so that we get log files and consistent build envs), then I disagree. There's a heck of a lot of other work that porters would be better off spending their time on -- like, for instance, the unresolved build failures of perl on arm. I mean, it's possible you're right that porters are going to feel slighted if they don't have buildd access; but shouldn't porters' primary motivation be to make sure etch releases with a kick-ass Debian port for their architecture of choice? Should this really be about who holds the keys to the buildds? Isn't being a Debian porter already something to take pride in? > If the Vancouver proposal is the constatation that the old model did not > work the solution is to change the model, not to expect that people will > suddenly accept it. Unless you are just looking at an excuse to remove > ports, obviously. Fortunately there are no external organisations forcing > the old model upon us, so there is no reason not to change it. All I really see here is that you've asserted that other (unspecified) porters should be given access to buildds that they don't necessarily want or need. Is this the new model you're referring to, or have I missed something? To be honest, it doesn't seem like much of a new model to me, just new people in the same roles. Cheers, -- 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