On Sun, Jan 14, 2001 at 10:06:34PM -0900, Britton wrote:
> > I mean, is it really difficult to see how approving someone who'll
> > maintain a couple of packages that'll get dropped into optional or extra
> > isn't really a high priority? Is it difficult to see how someone might
> The problem with this logic is that you don't have much chance of being
> able to accurately determine which maintainers are going to result in just
> a few package of this sort and which will do more, sometimes a lot more.
Well, having someone say "I'm going to setup and maintain an arm
autobuilder, have a look at http://foo.bar.org/~buildd/ where I've
already got it half working" versus someone saying "I don't really feel
comfortable doing more than one or two packages yet" seems a good start.
(cf, the Tasks and Skills check).
And I mean, it'd be nice to not need to prioritise people, but we still
don't seem to be able to handle the volume of new maintainer applicants
we have effectively, so we need to do *something*.
And while it'd be nice to have a dozen clueful, well known and highly
trusted people who can spend twelve hours a day every day just processing
new-maintainers, we just plain don't have a dozen clueful, well known
and highly trusted people who're willing to do that. We basically have
one such individual, and he's neither willing nor able to spend that
much time on n-m's (or so I'd presume).
So apart from wishful thinking, what's the point of worrying about it?
Wishing for something alone rarely makes it happen, worrying about a
problem and nothing more rarely makes it go away.
And lacking the copious free time and other things we might wish for,
we're left with trying to make the most productive use of what time
and resources we have. And, again, whining about this does nothing to
increase the time or resources available to us. [0]
> Finally, the debian packageing scheme allows for a high degree of parallel
> development, and it needs to, since we aspire to put a wrapper around
> every single piece of useful free software we can find.
And the Debian security model only allows us one line of defence against
incompetent or rogue contributors: new-maintainer.
Once someone's in, they can immediately upload a new version of libc
with whatever exploits they want, which'll get automatically included
in the archive and mirrored within twenty-four hours, and will then get
automatically installed on, at a guess, thousands of machines. They can
poke around on *.debian.org systems looking for security holes to abuse
in an attempt to cripple the system, they can lookup the home addresses
of other maintainers and work out whether they're currently on vacation,
they suddenly have access to machines behind some of our sponsors'
firewalls, they can setup some nice large wgets to try increasing some
of our sponsors' networking bills, they can probably run fork or memory
bombs on a few of our critical servers, they can setup an autobuilder
or two and accidently insert trojans in every other package you build.
To be truthful, this isn't our only line of defense: if any of this
stuff actually happens, we can almost certainly recover from it [1].
It's said that "an ounce of prevention is worth a pound of cure", though.
There may be some value to that line of thought.
Of course, there are alternatives. You could always introduce categories
of maintainers. Maybe declare people like Joey Hess to be "senior
developers" and give them full access to all machines and let them NMU
anything, and only let people like Mariusz or Daniel upload their own
packages. That'd probably be similarly effective at preventing exploits,
but it doesn't sound like an overly open, fun or productive project to
me, though.
> True, we have a
> massive influx of NMs, but there is a massive influx of useful free
> software,
I'd be interested in seeing an attempt at correlation between those
two. Certainly some new-maintainers are doing useful free software (eg,
someone from Xine upstream is in the n-m queue and intends to package
it, aiui) but it's far from clear whether that's the exception or the
rule. To go back to me as an example, when I joined I certainly wasn't
participating in a massive influx of free software (with a single non-free
package to my name).
Anyway, in summary: expecting James or Joey to do whatever's required
to make you, personally, happy, no matter how difficult or time
consuming or against what they personally think is proper is completely
unreasonable, and not remotely appropriate for a project populated by
volunteers. Wishing and asserting that there should be more DAMs, or
that DAMs should have or make more time is a pointless waste of time,
your own especially.
And all of this random bitching about how new-maintainers are treated
so unfairly without even a "I really appreciate how much Joey and James
have done for the project, but..." ? Call me old fashioned, but that's
just rude.
Cheers,
aj
[0] And, in the short term, approving most new-maintainers doesn't do
much to increase Debian's resources either. Adding, eg, Daniel to
the project means instead of being able to handle 6203 packages,
the project can handle 6205. Compare this to adding Chris and Phil,
who enable us to handle six architectures instead of five, or Neal who
gives us a second kernel, say. In the longer term it's a different
matter, of course. In a year or a month Daniel might turn out to
be an undiscovered genius and take Debian to levels of success we
can't even imagine right now.
[1] Sure, 1000 people will have to reinstall their systems after they got
cracked by "apt-get", and a few developers have to call their
insurance agency when they return from their holidays to find their
house completely emptied of cute gizmos and furniture, and maybe a
couple of our sponsors decide they can't risk helping Debian out, but
hey, what's that compared to a few weeks of irritation for some people
who're volunteering to help, after all?
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Thanks to all avid pokers out there''
-- linux.conf.au, 17-20 January 2001
Attachment:
pgpQbhimXXJM0.pgp
Description: PGP signature