Re: StrongARM tactics
On Thu, Dec 08, 2005 at 02:03:27AM -0800, Steve Langasek wrote:
> On Wed, Dec 07, 2005 at 04:48:24PM -0600, Bill Allombert wrote:
>
> 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
You wrote in this list in <20050606010553.GD5180@mauritius.dodds.net>:
Clone yourself and make yourself a slave to the buildds for 7 or 8
architectures, so that the release team doesn't have to. Neither the
release team nor the FTP team is interested in being responsible for keeping
all of these architectures afloat.
Given the intersection of {FTP team} and {buildd admins} is not empty
so this seems more an issue than just 'right amount of pleasure'.
In fact when a volunteer state they are no more interested to perform
a task, it is better to assign the tack to someone else before the
volunteer stop doing it, either progressively or at once.
In a thousand people project we simply cannot ignore social issue.
> 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.
In a project a thousand strong, surely finding someone that can handle
it should not be too hard ?
Probably the best way for someone to show capacities would be to act as
an unofficial buildd admin. This can work nicely for new,
not-yet-official ports that need an unofficial buildd anyway, but it is
rather unconvenient for official ports because this means to duplicate
needlessly the buildd infrastructure. This might even be taken in bad
part.
> 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?
I have no reason to believe either, why should have ?
I certainly did not intent to make any claims that buildd maintenance
was exciting or rewarding, only that it was a necessary responsibity
for a port.
> > 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.
Which means that on 5 architectures, the buildd admin is not interested
enough to be a porter.
> So it's certainly not the case that no porters are trusted to do binNMUs.
So there are 4 architectures where no porters have wanna-build access ?
For theses architectures, no porters are trusted to do binNMUs. What
happens on the other platforms is irrelevant to them, that only make them
at a disanvantage;
> 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?
I did not mention motivation either. The issue is one of responsibility not
motivation.
I am only arguing that is it inefficient to have buildd admins that are
not porters. Reasonnable people avoid working under inefficient schemes
and move to other venues. Debian is so large that it is uncommon to be
motivated to do only one thing.
> 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.
I don't think I proposed any new model, but since you ask me:
My model would be to have buildd admins willing to act as porters.
Which probably imply that we will have more buildd admin rather than new
one.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: