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 accessible". > 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. Cheers Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
