On Thu, Feb 15, 2007 at 10:00:25AM +0100, Frank K?ster wrote:
> >> > > i think someone running more than one autobuilder for more than _two_
> >> > > years now (okay, not for the officical archive, but i see that as
> >> > > nonrelevant here) demonstrats very good that he mets your mentioned
> >> > > technical constraints.
> >> I didn't thought of Aurelien, but of a few other persons, who are acting
> >> as buildd maintainers for experimental and non-free packages.
> > Experimental and non-free packages go to the official archive... I'm
> > not seeing what you're asking for here.
(If there's something more than the general comments Frank made,
I'm still not seeing it. TTBOMK, the non-free and experimental builds
aren't at all integrated with the buildd.d.o stuff, and there's been
no particular interest in changing that. If that's not the case, it's
probably worth talking about sometime)
> Are you so overworked, or are you deliberately "forgetting"? It has
> been suggested multiple times in the past to use existing or new
> hardware and add it to the set of standard autobuilders. Many arches do
> not meet the redundancy requirement, and we don't have autobuilders for
> i386 at all AFAIK. Moreover, the current buildd admin's apparently
> don't have adequate time to communicate, which could be ameliorated by
> adding people. Even if nobody had asked so far, we should ask people
> who seem capable of doing it.
I've been thinking for a few days now that people in Debian disagree
too much (hence the comments preceding my responses to Raphael in an
earlier message), so starting now, I'm going to stop replying to mails
by focussing on differences, and start with agreements. Let's see how
long it takes until I can't stop myself from adding a "but".
[0]
There are a number of serious problems in how the Debian infrastructure's
managed. That may be too strong: I mean to say that they're important,
without being critical to be solved immediately [1]. And often the impact
of these problems is to block other people's attempts to contribute to
Debian, and in so doing disrespect their contributions and discourage
further contributions, though in some cases those contributions are
"merely" thrown out as "collateral damage" along with something that
should be blocked, whether that be a buggy upload or some changes that
need further review.
The right way of dealing with that is to work with the potential
contributor to ensure they understand the issues that're involved so
that their future contributions can be accepted and will be useful. IMO,
that applies whether the contribution's a patch, or an emulated buildd. I
guess I'd argue that it applies to existing contributors too, if you want
to critique their performance. I've found it difficult to work up the
energy to try working with potential contributors on this score because
there seems to be so much rage about the way things work now that I can't
really imagine reaching that level of mutual understanding. I can't say
I like that state of affairs much.
Anyway, I already have a related email that I've promised to send out that
I hope will show something of a step towards fixing these problems. I
think I'm going to bow out of the discussion for the minute until I
can get that off my plate. Unfortunately, that'll take longer than YA
inconsequential mail where I'm able to just write what I think...
[2]
Cheers,
aj
[0] Or if I can even work out how to start the next paragraph without a
"but"...
[1] They're mostly long-term problems, so if they were critical,
frankly we'd not be having this conversation, and people wouldn't
be asking if Debian was dying, they'd be getting us confused with
AmigaOS...
[2] Wow, I'm really in the habit of qualifying everything I write. That
was much harder than I expected...
Attachment:
signature.asc
Description: Digital signature