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

Re: Binaryless uploads [Was: FTBFS: architecture all packages]



[ Note the Mail-Followup-To; I subscribe to the list, and don't need a Cc ]

On Tue, Aug 19, 2003 at 10:21:02AM +0200, Wouter Verhelst wrote:
> Op di 19-08-2003, om 06:38 schreef Joel Baker:
> > > People seem to be doing quite well enough at catching those
> > > already. As you're so fond of saying, if they weren't then we wouldn't
> > > be having this conversation (note how meaningless that is?).
> > 
> > Primarily because a few individuals appear to be doing, on their own time
> > and bandwidth, exactly what I propose - that is, invoking the binary-indep
> > target on a building machine other than the maintainer's.
> > 
> > If they get hit by a bus, reassigned by their job to Outer Mongolia, or
> > just plain get bored with doing it, we lose that benefit entirely, as
> > things stand today.
> 
> Sure, but that applies equally well to anything within Debian. If, e.g.,
> aj or james get hit by a bus, we'll have a serious problem. And that's
> even a bigger thread, given the fact that james and aj do things not
> many other people do and which likely requires some training and
> experience to do it right, whereas rebuilding and filing bugs is done by
> quite a few people, and only requires the motivation to do it.
> 
> This argument hits no ground, sorry.

If Aj or James get hit by a bus, there is a clear and well-established
method of transitioning; both positions can be re-appointed by the DPL, and
there are a number of people who have demonstrated sufficient skill to pick
such things up and run with them, at least long enough to get out of any
impending crisis (and quite possibly longer).

In fact, most of their duties are *already* split out to avoid exactly
this possibility; we have more than one DAM (or so it was stated in recent
threads), with the other(s) being "backup DAMs" who can step in for exactly
this sort of thing. The RM position has assistants, most of whom could step
up to bat, as well as people with a prior track record who might be willing
to handle it for long enough to stabilize things. And ftpmaster is already
a team effort, supposed.

So, tell me again why it's a good idea to depend on one person with a
machine not even handled by Debian to be the sole point of failure that
costs us a valuble service? Critical, no - which is why it's manageable to
have the situation. That doesn't mean it's optimal, or that we shouldn't
change things to become more optimal.

And, of course, this doesn't even mention the fact that having many
people rebuild packages either means A) massive redundancy (if they're
all rebuilding a significant portion of them), or B) spotty coverage, if
they're all rebuilding only what they care about or randomly pick.
-- 
Joel Baker <fenton@debian.org>                                        ,''`.
Debian GNU NetBSD/i386 porter                                        : :' :
                                                                     `. `'
				                                       `-

Attachment: pgpgC2zu4E5Bs.pgp
Description: PGP signature


Reply to: