Re: Unofficial buildd network has been shut down
On Wed, Sep 01, 2004 at 11:37:19AM -0300, Henrique de Moraes Holschuh wrote:
> We should act as a whole on security matters. If we decide that "third
> party run" autobuilders are okay (for some definition of third party), then
> they are okay for *everyone*. Otherwise, they must "not be okay" for
> anyone, or any security implications are being thrown out the window.
Well, they were fine for several years now. Nobody objected so far, but
appreciated the extra CPU power. Why is this different now, just because the
same persons just runs 6 instead of 2 machines?
> Pehaps. But we can try to address the real issue behind the matter, which
> is not one of trust, but one of a perceived need for more autobuilders.
Well, I have to trust the people as well that I grant sudo access to my
boxes. Anyway, the most interesting part comes now:
> We could, for example, try to:
> 1. Create a "NM" (really, new porter) process directed at buildd managers
> and porters. We already have one for maintainers, and one for
> documentation writers.
Yes, I totally agree on that.
For example one of the reasons why I haven't apply for NM so far was the
reason that I don't intend to do any kind of packaging, but I always had the
feeling that the NM process is heavily dealing with exactly this: package
building.
I found my niche in Debian with making buildds available and keep then
running, get to manage new hardware and stuff. And I think, I'm doing quite
well in my niche...
> 2. Go ahead with the idea of roles in debian. A "builder/porter" would
> need to have as much trust as a "package maintainer", since the
> security implications are about the same. The social implications are
> not the same, if the builder can stay quiet while wearing his Debian
> hat (or they are the same if not). Theorically, a builder has much
> less contact with the users than a package maintainer. The set of
> skills is a bit different, as well.
Well, not much contact with Joe User, but with Joe Maintainer. There's much
mysticism floating around about buildds and how they works. You can see some
effort on clarification on this when looking at buildd.net.
> 3. Start beefing up the team that takes care of the autobuilders as a
> whole, so that we can easily beef up the number of autobuilder machines
> for each arch on those that cannot keep up with i386 (I expect that in
> one year or two, the lead arch will change, and i386 will need to have
> two or more autobuilders to keep up :) ), AND THE NUMBER OF BUILDD
> ADMINS FOR EACH ARCH.
>
> (3) needs acceptable volunteers, whatever that means. And hardware
> with an acceptable administration profile, which I am not sure if it is
> a problem right now or not.
If have had some thoughts about some sort of a buildd team during the last
two weeks, too. In fact, there was a team already forming by the dictum of
stepping in and doing the work that needs to be done.
I would like to see that team of volunteers (be it DDs or non-DDs) to form
such a working group and maybe elaborate guidelines for new buildds and
buildd admins.
> IMHO it is clear that it would be a good goal to have at least two active
> people responsible for any given arch (with access to *all* autobuilders for
> that arch, so that a set of packages does not get stranted because they were
> built, but there is no one with access to sign and upload them). And that
> we have a reasonable number of people doing this as a whole (certainly more
> than two!) and for the common build infrastructure, for the same reasons.
> More resiliency is good. Workload sharing is good.
Well, I'm advocating this for about a year now, so you have my support on
this. ;)
With the current rate Debian is growing, there need a path for the
autobuilders how they can achieve with that growth in the future.
M68k was the "evil" arch when woody was released, but the number of "evil"
archs has grown and the archs are others now. M68k has learned its lesson
well. The port has established a high number of buildds *before* the release
started. It performs well even when *several* machines are offline for some
days.
I think that other archs can learn from the m68k port in these regards.
Of course, m68k is not the fastest arch on earth, but compared to way faster
archs, it performed extremely well with the extra load of an upcoming
release. This time alpha, mips, mipsel and arm had problems. Which archs
will have serious problems to keep up next time?
--
Ciao... //
Ingo \X/
Reply to: