incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Abele <e...@codefaktor.de>
Subject Re: The Incubator and Infrastructure
Date Fri, 02 Sep 2005 12:23:01 GMT
On 02.09.2005, at 13:03, Niclas Hedhman wrote:

> On Friday 02 September 2005 17:42, Leo Simons wrote:
>
>> By all means, please help make it happen! Step 1 is subscribing to
>> infrastructure _at_ apache _dot_ org, if you haven't already.
>>
>
> After almost 2 years of trying to find angles of helping out, I  
> finally gave
> up and unsubscribed a few weeks back.

This is soooo ridiculous... just look at Leo: some time ago he was  
'just' a committer, now he is a member and got even root access! Same  
with me and a lot of others. We were not born as ASF roots, just look  
at the archives: some years ago I started to explore our  
infrstructure as a committer, sent in patches to areas I had already  
access to and then, as people saw that I was working constructively,  
I got more and more karma. Why isn't that working for others?

> Outsiders receives little insight how everything is done, the  
> infrastructure
> repository is closed (although the realm says "ASF Committers" it  
> is probably
> set to members) and the bits and pieces that are open, must be dug up
> elsewhere.

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. Furthermore you can find nearly  
everything on the machines itself, mostly world-readable; so the repo  
won't help you if you don't know where the live checkouts are living  
and how everything is pulled together. And if you are looking for  
documentation in there, you'll be disappointed - it's just too  
specialized on the different root or apmail tasks...

> Sorry to say, I think infra@ overload is self-inflicted, being  
> disorganized,
> non-transparent and "put out fire by hand" instead of preventive  
> measures,
> automated procedures and "product development" attitude towards the  
> tools.

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

To lower the load on this seemingly simple task, we tried to come up  
with an utterly simple mechanism to request an account: 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. The whole process is described in detail on the  
website, we sent numerous educating emails about this. So, what would  
you expect to happen?

Well, 80% of the requests root@ were receiving for a long time were  
completely out of sync with this process (e.g. CCs missing, CLAs not  
recorded, wrong spellings, completely different format, email  
mistakes, bounces, request not by the chair, etc. etc.) - it's  
slightly better now, but I hope you get the point ;-)

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. 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?

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.

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 :)

> Well.... Good luck with your baby steps.

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 :|

Cheers,
Erik


Mime
View raw message