Re: New-maintainer - STOP THAT SHIT
>
> --kvUQC+jR9YzypDnK
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> 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).
Stop twisting my words.
What I said is that I don't want to jump into the deep end. I want to
eventually maintain as many packages as I usefully can (i.e. as time and
skills permit). What I DON'T want is to jump out blazing with 23 packages,
and then get 6 months behind in them because I haven't quite figured out how
to skilfully manipulate the BTS, or because of a small bug. I'd rather have
people say, "He may only do 3 packages [for now], but he does a bloody good
job." than "These are all fucking useless. Why do I bother?" I said starting
in the baby pool, Anthony. Not staying there.
> 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*.
Like, get the DAM part to work effectively? Anyway, how do the priority and
volume arguments tie in? I think prioritizing people is wrong,
<flamingheapofsarcasm>because the existing sponsorship system works so well,
right? And people don't need the "magical ring of Debian Developership" to do
"real work", right?</flamingheapofsarcasm>
> 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).
Or, better DAMs. The AMs themselves are fine. My AM (hi Gregely!) was
absolutely brilliant, always polite and helping me out, pointing me in the
right direction, etc. No complaints about the AMs.
> So apart from wishful thinking, what's the point of worrying about it?
Because it pisses people off?
> Wishing for something alone rarely makes it happen, worrying about a
> problem and nothing more rarely makes it go away.
Or, suggesting solutions that work (i.e. DAM, etc), and talking
constructively about it (well, some parts of this thread, at least) about
it, they work bloody well in my experience.
> 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]
Look, there's a difference between whining and complaining. This is a
legitimate complaint. The NM process is a PAIN IN THE ARSE. If I had 1c for
every single time a current developer had told me "If I had to go through
all of this rigmarole then, I wouldn't have bothered," I would be able to
buy that new computer you're talking about by now. This is legitimate, and
something needs to be done about it.
> > 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.=20
>
> And the Debian security model only allows us one line of defence against
> incompetent or rogue contributors: new-maintainer.
So, how does the DAM stopping the queue fix this?
> 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.
Which is why we have the P&P check, the T&S check, and the ID check. Script
kiddies would NOT have the patience to wait a year, sometimes more (18
months from one I heard), just to do something like that. Packeting from
Romania seems to work just fine so far. We have enough checks and balances
in NM already. More than most places that actually EMPLOY people have. (And
I'm talking places with multiple redundant OC-48's, high security data
centres pumping through a few thousand transactions a day with home
addresses, credit cards, etc, etc, all on the databases). This, this is
enough.
> 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.
See above. That's why we already have the NM system.
> 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.
Sounds like another layer of beauracracy to get anything done to me. Which
sounds bad, bad, bad. Keep it equal. (Plus: who decides on the "senior
developers" bit, anyway? It's going to be biased, either way, because, if
it's, say, Ben Collins, I would never, ever get any access at all).
> > True, we have a
> > massive influx of NMs, but there is a massive influx of useful free
> > software,=20
>
> 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).
I package what I can, however my coding time lies in the kernel -
specifically, Netfilter. Both the kernel and iptables are already taken,
sorry.
> 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.
I don't expect them to make me personally happy. I expect them to not wield
authority they DO NOT HAVE (Joey). There's also a thing called trust, and I
dunno about you, but I damn well try my hardest to not break any trust I
have with anyone. Ever. It's just not done.
And why is pointing out that the DAM stage is the biggest bottleneck in
Debian and needs to be fixed, soon, pointless? And a "waste of time"?
Look, if something gets done, then none of this has been a waste of time.
Except maybe the bit where Ben argued the same point as me, but tried to
make it look like it was an argument, and we were on opposing sides.
> 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.
They pay us out, we pay them out. It works both ways, AJ. I don't take shit
without giving any (well, very rarely). Some people try to tie in "respect"
and "authority", but, to be honest, I don't care.
> 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.
Yes, but if we add 72 new maintainers, even if they're all pissants like me,
that's 6347 packages, instead of 6203. Vive la difference! And how do you
know I'm not a genius? ;) (72 is the current amount waiting DAM approval
iirc).
> [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
OOOH! Let's stop publishing the White Pages, RIGHT NOW! It has people's
addresses in it! SECURITY HOLE! Puh-leeze.
> 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?
See my previous points about the current NM process. There's more than
enough checks and balances.
d
Reply to: