[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: StrongARM tactics

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.

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

Reply to: