incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: The Incubator and Infrastructure
Date Fri, 02 Sep 2005 15:25:29 GMT
On Friday 02 September 2005 20:23, Erik Abele wrote:

I honestly don't feel like "fueling" this thread, so please don't hesitate to 
say I am outright stupid and don't know what I am talking about, and I'll 
shut up as a good citizen... My intention is not to "whine".

> Why isn't that working for others?

Yes. Why?
My take is that only one in 300 committers have what it takes to "get thru". I 
was not one of them... Can that ratio be improved? If it takes 10 people to 
keep the ship afloat, (as a manager) I would plan for at least one person 
leaving every quarter, and that would then set the minimum recruitment pace.

> The infra repo isn't the almighty tool everyone needs. Most material
> in there (if not all by now) isn't instantly useful if you are not on
> top of the different setups. 

Ok. So I don't need to bother about the docs, since they may confuse me even 
more? Good start.

> Furthermore you can find nearly 
> everything on the machines itself, mostly world-readable; 

I noticed a pluralis of "machines". AFAIK, only minotaur is "world 

> a) overload is self-inflicted
> Uh oh, just consider the following example: account requests.

How long can it possibly take? 
Let me make a guess ~1 minute, perhaps 2. Let's say I spend half an hour a 
day, that makes it 15 a day, and several thousand per year. Apparently, this 
can't be a bottle neck.

> - pmc votes in new committer, 
> - makes him sent in a CLA; 
> - the PMC chair watches for the receipt of the CLA and if it gets recorded, 
>   he sends a single email to root@ (cc'ing the PMC) in a pre-defined 
>   format and waits till the account is created. 

Great. So it is not a problem, anymore?

> b) being disorganized
> Maybe, but keep in mind that we are all volunteers and that not only
> the ASF is growing tremendously, our hardware/infrastructure needs
> are doind so too. Old systems and services have to be kept running
> for projects who want to still use it, new systems and services have
> to be put in place (and administered) because projects are begging
> for it. The complexity is growing daily. 

I recognize that. And I happen to be of the opinion that it is self-inflicted. 
Leo wrote a humorous mail about it two months ago "Why we say no.". And just 
like projects don't have a choice of CVS, such policy could be introduced for 
Jira/Bugzilla/Scarab (any other?) as well, if it is seen as a taking up 
precious time.

> Ask Leo and Upayavira how 
> easy it is to set up a wiki (which btw, is running excellently for
> some committer's company: 'our 22 developers cannot live w/o it, why
> the heck isn't this available at the ASF?') for billions of clicks
> per day?

I agree, and again refer to the "Why we say no" and "self-inflicted"...

> c) non-transparent
> Hmm, IMO infra is *not* non-transparent; it's just that the bar is
> pretty high (knowledge-wise and confidence-wise (in the sense of
> trust)). Please give me an example of what is so non-transparent; I'm
> willing to help you here.

Example 1. You said it yourself -> docs are "shaky", but I could live with 
that. The problem is "everyone knows they are not good" and it has been 
hinted that a lot of material is outright wrong. That makes it even worse.

Example 2. Most requests comes in as either a mail or a Jira issue. Some time 
later, someone like yourself, mark it as "done". If I was overworked, and 
that I wanted others to get involved, I would spend more time explaining what 
I did to make it "done" than I did to "do it". *In detail*.
Over "my time", that rarely happened, and I took it as "they don't want help 
with that".

Example 3. I think that most resources are turned off by default, and only 
after long considerations, made accessible (read and/or write) to a wider 
audience. That is natural security awareness kicking in, but little 
discussion is going on, about how to make more info available. Can other 
people watch this configuration? I have always been of the opinion that ASF 
is more secretive than the situation calls for.
The fact that many services live on machines that are not accessible, makes it 
difficult to peek around to get an idea of how things are setup, without 
"bothering" the peeps who do the work, since it is likely I won't be able to 
help "in that particular area" right now.

> d) "put out fire by hand"
> Well, that's the occasional hdd failure or worm attack or svn wedge
> or ... . It's pretty hard to come up with automated solutions to
> every problem so administering a system always means to baby-sit it
> in some way. If it would be solvable by a click on a fancy button,
> the managers could do it and we wouldn't need any sysadmins anymore :)

I get the impression by your response that there are no problems, or overload 
at the infra@ team. Catastrophic events can't be automated, but they happen 
rarely. All the 'bulk' is already streamlined, and shouldn't take much time. 
So what is it? Full time staff is needed, so there must be something.

> Thanks, I'm nearly outta here too - it's far more easy to support my
> own systems which have to take care only for a couple hundred users
> per second and not millions and, ah, making a living out of it
> instead of just fighting with a huge amount of of whining people,
> materializing in hundreds of emails :|

Erik, in case no one has expressed it before; A Big Thank You!!! You, Noel, 
Leo, Justin and everyone else are providing a wonderful service. That is the 
external interface, and I think you manage that well.

If mails are a problem, disable the mailing list and require Jira to be used 
as the medium to communicate with the infra@ team.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message