Re: The Incubator and Infrastructure

2005-09-04 Thread David Crossley
Noel J. Bergman wrote:
 David Crossley wrote:
 
  I suggest that we go further and make it a requirement
  of graduation from the Incubator that the project
  already has some people helping at infra@
 
 That can only apply if there are ASF Members willing to do it, because we
 don't give apmail or root access to non-Members.  And not everyone wants or
 feels competent to manage the tasks.
 
 What tasks did you have in mind?

Anything. Even just answering other users queries.
That will relieve the other infra people to attend
to the new project's core needs.

I want to instill at the beginning that we all
need to look after our own ASF - love your Infra.
If you want to participate in a project, then be
prepared to assist with the general infrastructure.

Leave the rest of this account creation type stuff
to the main infra people ...

-David

  Seems to me that account creation is
 primary, followed by mailing lists.  Otherwise, people can contribute
 documentation and automation tools.  We have a new proposal that we should
 take a good long look at regarding automation.
 
 We could give more people karma to write the account request file, so that
 the roots need only to run the script to effect the changes.  We still don't
 have workflow in place to enforce it, but what if we had the script check
 the CLA records and emit only those for which the e-mail addresses match?
 
   --- Noel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: The Incubator and Infrastructure

2005-09-03 Thread Noel J. Bergman
David Crossley wrote:

 I suggest that we go further and make it a requirement
 of graduation from the Incubator that the project
 already has some people helping at infra@

That can only apply if there are ASF Members willing to do it, because we
don't give apmail or root access to non-Members.  And not everyone wants or
feels competent to manage the tasks.

What tasks did you have in mind?  Seems to me that account creation is
primary, followed by mailing lists.  Otherwise, people can contribute
documentation and automation tools.  We have a new proposal that we should
take a good long look at regarding automation.

We could give more people karma to write the account request file, so that
the roots need only to run the script to effect the changes.  We still don't
have workflow in place to enforce it, but what if we had the script check
the CLA records and emit only those for which the e-mail addresses match?

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The Incubator and Infrastructure

2005-09-02 Thread Henri Yandell
On 9/2/05, Niclas Hedhman [EMAIL PROTECTED] wrote:
 On Friday 02 September 2005 10:28, Davanum Srinivas wrote:
  Several people on WS-PMC offered to help infra. They were turned down
  as they are not members.
 
 This has been my impression as well.
 
 infra@ is begging for help, but seems to have problem with;
 
  a. only members allowed in for the stuff that each projects
 PMC Chair can't do already.
 
  b. requesting people without access to help out on answering
 questions, which more often than not, requires peeks into
 files that such volunteer doesn't have access to, or to
 places that may or may not be documented.

As someone currently sinking into the mire of infra having just become
a member, I have to agree; the work available for the average
committer isn't very clearly identified.

This has improved, Bugzilla-Jira migrations are now in danger of
happening and although Henning is a member, Tim isn't and I don't
think Henning's member-ness is relevant to the work.

Answering user questions on the infra@ mailing list is always useful,
especially given the infra-private@ bit below.

 Leo,
   There are three ways to ease the burden on infra team, and I think all are
 wanted;
1. reduction of requests coming into infra@ (this thread covers that),

Also partly solved in a different way. infra-private was created for
dealing with the emergencies/big-bad-things (hard-drive blown up,
minotaur fscks, giving access to volunteer ).

The infra@ mailing list has moved more towards user requests and some
of the core people have the chance to opt out of this list now.

2. more hands to help out,

Thus the volunteer requests.

3. more tools to automate.

Leo's been behind a lot of design plans for that, and there's a CA
tool looming on the horizon. An improvement here would be for someone
(Leo?) to give us a better overall plan of what's requested and where
it fits.

One of the problems with this is that you still need a certain access
to handle some of them, or at least a certain amount of knowledge of
how the system works.

I think there may be an infra-tools@ list that I didn't join to
discuss these. Can't remember if that happened or not.

There's another one too. Get involved with the [EMAIL PROTECTED] mailing
list (I think that's the correct one?); discussing ways to provide a
site building zone and how to handle that kind of stuff.

 I am specially curious of what can be done about 3.
 ASF consists of (allegedly) more than a 1000 committers. How hard could it be
 to find a couple that are capable of putting this in place? Very. Since only
 members are allowed in, they are busy elsewhere and infra team has no time to
 extract all the details for someone to implement these independently, or so
 it seems.

We're all here to scratch our itches, writing code for Infra doesn't
scratch the itch unless you've been sucked into Infra. But you're
right, cornering Leo into drawing a picture of Infra, what bits are
where and what bits can be automated would be useful. Leo, will you be
at ApacheCon? :)

 As for more hands, I think the infrastructure team needs to compile a list of
 what committers, members and root must do. Once you have identified work that
 committers can do, members should volunteer higher up the ladder, and
 likewise for roots.

Yup. My first worry was on what the existing people were doing and
where we were lacking backup, so I've a very rudimentary form of this
with people's actual names attached. I'll work to genericize this and
try to put in more tasks, and hopefully find out where there are
actual problems. SVN migrations are ticking along quite nicely for
example, so no great need to throw more resource at it (unless it's
people telling us that they're ready to migrate, hint hint).

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The Incubator and Infrastructure

2005-09-02 Thread David Crossley
Henri Yandell wrote:
 Niclas Hedhman wrote:
  Davanum Srinivas wrote:
   Several people on WS-PMC offered to help infra. They were turned down
   as they are not members.
  
  This has been my impression as well.
  
  infra@ is begging for help, but seems to have problem with;
  
   a. only members allowed in for the stuff that each projects
  PMC Chair can't do already.
  
   b. requesting people without access to help out on answering
  questions, which more often than not, requires peeks into
  files that such volunteer doesn't have access to, or to
  places that may or may not be documented.
 
 As someone currently sinking into the mire of infra having just become
 a member, I have to agree; the work available for the average
 committer isn't very clearly identified.

We have eased that problem a bit lately. If committers
show interest, then we will grab them and add them to
an infrastructure-interest group which has access
to certain areas of infra SVN. This happens on a
case-by-case basis.

-David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The Incubator and Infrastructure

2005-09-02 Thread Leo Simons
On 02-09-2005 04:28, Davanum Srinivas [EMAIL PROTECTED] wrote:
 Several people on WS-PMC offered to help infra. They were turned down
 as they are not members.

NACK. There are lots of ways to help. I remember writing several e-mails
detailing how. There are several non-members actively helping out with
useful stuff. Heck, there's a non-committer or two doing the same. But no,
infra@ is not going to give out root access to people pretty much unknown to
the team.

- LSD



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The Incubator and Infrastructure

2005-09-02 Thread Leo Simons
On 02-09-2005 08:27, Sanjiva Weerawarana [EMAIL PROTECTED] wrote:
 On Fri, 2005-09-02 at 14:19 +0800, Niclas Hedhman wrote:
 Now, I have suggested before, and still do, that infra starts/becomes a
 standard ASF project, source code, site, jira, wiki, dev mailing list and all
 the normal setup, including ordinary committers and contributors.

Indeed. Many people have. We discussed this stuff a lot during AC EU. The
existing infra team doesn't feel like rash changes (which is a Smart Stance
To Take and deserves Community Support) so we're taking baby steps along a
similar path. You can help us take those steps.

 Infra 
 places the requests of tools to be made into the Jira there and let evolution
 take over.
 
 I also suggested this a while back but was given the brush off :(.

Hrmpf. There's actually a few concrete requests in jira for help. There's
been one for years (with detailed specs and all) regarding CLA/user account
handling automation, which was even sent to committers@ at some point
(yielding a total of 0 volunteers at that time). Everyone is welcome to
submit patches to

  https://svn.apache.org/repos/asf/infrastructure/apworkflow/

(really cool stuff! Python+subversion based web application with wiki-like
functionality! Several page todo list! Everyone come out and play!) And
you're likely to get write karma at the first sign of a second useful patch.

 I hope it'll get traction this time around - IMO its the only way to
 solve the infra issue (short of outsourcing infra to SourceForge ;-)).

Its *part* of the solution :-)

In any case, this ain't the mailing list for these discussions!

Cheers,

Leo



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The Incubator and Infrastructure

2005-09-02 Thread Niclas Hedhman
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.

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.

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. 


Well Good luck with your baby steps.

Niclas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The Incubator and Infrastructure

2005-09-02 Thread Davanum Srinivas
Leo,

Specifically 2 people asked read persmissions on the files. they were
told that's not possible. Am NOT talking about root privs.

-- dims

On 9/2/05, Leo Simons [EMAIL PROTECTED] wrote:
 On 02-09-2005 04:28, Davanum Srinivas [EMAIL PROTECTED] wrote:
  Several people on WS-PMC offered to help infra. They were turned down
  as they are not members.
 
 NACK. There are lots of ways to help. I remember writing several e-mails
 detailing how. There are several non-members actively helping out with
 useful stuff. Heck, there's a non-committer or two doing the same. But no,
 infra@ is not going to give out root access to people pretty much unknown to
 the team.
 
 - LSD
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


-- 
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The Incubator and Infrastructure

2005-09-02 Thread Erik Abele

On 02.09.2005, at 14:07, Davanum Srinivas wrote:


Leo,

Specifically 2 people asked read persmissions on the files. they were
told that's not possible. Am NOT talking about root privs.


Which files? Why? Who?

Cheers,
Erik


-- dims

On 9/2/05, Leo Simons [EMAIL PROTECTED] wrote:


On 02-09-2005 04:28, Davanum Srinivas [EMAIL PROTECTED] wrote:

Several people on WS-PMC offered to help infra. They were turned  
down

as they are not members.



NACK. There are lots of ways to help. I remember writing several e- 
mails
detailing how. There are several non-members actively helping out  
with
useful stuff. Heck, there's a non-committer or two doing the same.  
But no,
infra@ is not going to give out root access to people pretty much  
unknown to

the team.

- LSD



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






--
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service  
Platform


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






smime.p7s
Description: S/MIME cryptographic signature


Re: The Incubator and Infrastructure

2005-09-02 Thread Davanum Srinivas
Sal and Ian from HP expressed interest on [EMAIL PROTECTED]:
http://marc.theaimsgroup.com/?l=webservices-generalm=111901932102075w=2

I gave them the pointers:
http://marc.theaimsgroup.com/?l=webservices-generalm=111901966108282w=2

They started a thread in infra@ mailing list:
[EMAIL PROTECTED]

See the end of the thread, they asked for read-only access to infra
stuff to read the FAQ and README's:

Then they attempted to ask on #asfinfra for the same permissions to
read material and get to know stuff. That's where they were given the
brush off.

Sigh! the SVN module http://svn.apache.org/repos/asf/infrastructure/
should be at least viewable by committers if you want/expect them to
help.

thanks,
dims


On 9/2/05, Erik Abele [EMAIL PROTECTED] wrote:
 On 02.09.2005, at 14:07, Davanum Srinivas wrote:
 
  Leo,
 
  Specifically 2 people asked read persmissions on the files. they were
  told that's not possible. Am NOT talking about root privs.
 
 Which files? Why? Who?
 
 Cheers,
 Erik
 
  -- dims
 
  On 9/2/05, Leo Simons [EMAIL PROTECTED] wrote:
 
  On 02-09-2005 04:28, Davanum Srinivas [EMAIL PROTECTED] wrote:
 
  Several people on WS-PMC offered to help infra. They were turned
  down
  as they are not members.
 
 
  NACK. There are lots of ways to help. I remember writing several e-
  mails
  detailing how. There are several non-members actively helping out
  with
  useful stuff. Heck, there's a non-committer or two doing the same.
  But no,
  infra@ is not going to give out root access to people pretty much
  unknown to
  the team.
 
  - LSD
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 
  --
  Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service
  Platform
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 
 


-- 
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The Incubator and Infrastructure

2005-09-02 Thread Erik Abele

On 02.09.2005, at 14:45, Davanum Srinivas wrote:


Sal and Ian from HP expressed interest on [EMAIL PROTECTED]:
http://marc.theaimsgroup.com/?l=webservices- 
generalm=111901932102075w=2


Quoting: What are the steps for me to get set up w/ admin
rights for SVN? Once I get set up, I'll read up on how to do basic SVN
admin tasks, and then try to knock out some of the easier issues in  
JIRA.



I gave them the pointers:
http://marc.theaimsgroup.com/?l=webservices- 
generalm=111901966108282w=2


Quoting: ...There are various readme's in infrastructure SVN. ... In  
your intro

email, specifically mention that you are on the WS-PMC, want to help
with mailing lists and SVN and that you can start with the pending
tasks of migrating stuff off of incubator.

Dims, come on - this is not the way the ASF works. What would you do  
if someone came to one of the WS dev-lists and asked: Okay, I'm  
willing to help, give me committership and I'll see where I can help  
out with some commits... - huh?


Isn't it rather in the line of: Hey, I've found a problem and worked  
out a solution, here it is (e.g. a patch), can we integrate that? -  
same with infra: hey, i found some SVN issues in Jira. I've set up a  
test repo in my homedir and imported their CVS module, looks good so  
far. Can we integrate that with the live repo and shut down the CVS  
module after the developers confirmed that everything is fine?


That's the difference, you know ;-)


They started a thread in infra@ mailing list:
[EMAIL PROTECTED]

See the end of the thread, they asked for read-only access to infra
stuff to read the FAQ and README's:

Then they attempted to ask on #asfinfra for the same permissions to
read material and get to know stuff. That's where they were given the
brush off.


There is no real documentation in the infra repo regarding this. It's  
all public: http://apache.org/dev/cvs2svn.html - what do they need to  
resolve these JIRA issues? Can they look at them, think about them  
and then come up with specific requests?


For example: Someone is asking for karma for XXX in JIRA; from  
reading the list and the website, I guess he will have to be added to  
the file minotaur:/x1/svn/asf-authorization but I don't have karma to  
do this by myself so here is a patch... - do that and I promise  
you'll be in in the near future :)



Sigh! the SVN module http://svn.apache.org/repos/asf/infrastructure/
should be at least viewable by committers if you want/expect them to
help.


Sigh! I don't understand why this repository is so important before  
opening up a terminal, ssh'ing to minotaur.apache.org, sitting down  
and looking around?!? That's a mystery to me but so be it and afaiac  
I'd be fine with opening it up since we scrubbed every bit of  
sensitive information in there some time ago...


Cheers,
Erik


smime.p7s
Description: S/MIME cryptographic signature


Re: The Incubator and Infrastructure

2005-09-02 Thread Niclas Hedhman
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 

Re: The Incubator and Infrastructure

2005-09-02 Thread Erik Abele

On 02.09.2005, at 17:25, Niclas Hedhman wrote:


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.


Your last msg was quite fueling, no? ;-)


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.


Uhm, 'recruitement' (in the managerial sense) doesn't really work in  
a volunteer-driven organization with collaborative and meritocratic  
development processes... you can of course encourage people but  it  
seems that that unfortunately doesn't really work with the unsexy  
jobs of [EMAIL PROTECTED]



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.


I didn't say that; all I said is that the infra repo is not our  
primary documentation place for beginners. It's just the place where  
we keep configuration files like crontabs, dns zonefiles, the httpd  
config and so on. There is also a limited set of documentation but I  
wonder why a infra newcomer has to know things like how to access the  
terminal server or how the network in the colo is set up.



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.


Yep and that should be enough to show that you know what you are  
doing and that what you are doing is goodness...



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.


You snipped the most important failures so trust me that it isn't  
done within a 1 minute. But that just shows the ignorance (not  
necessarily willful) we are facing, see below.



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


If everybody would follow this scheme it would be nice but as I said,  
nobody is doing so. Well, to be correct and fair, nobody *was* doing  
so, it is really better now with respect to account requests - but  
that was just one of a bunch of examples to make my point clear: even  
if we have a process and documentation in place, we are still facing  
a lot of people not following the process, ignoring the documentation  
and whining and pestering to get their work done :(



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.


Yes, infra could say 'no' more often or could simply shut down the  
services they don't want to administer. To be honest, I'd be fine  
with this (and its consequences (people/projects leaving, flamewars,  
what-have-you)) but since I don't want to discuss this in hundreds of  
emails, I'll simply leave and let others take over. No harm done.



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.


Okay, but that is not 'non-transparent' - the bar is just higher. I  
agree that it'd be nice to have more docs but OTOH the people have to  
also read them, see my 

Re: The Incubator and Infrastructure

2005-09-02 Thread Justin Erenkrantz
--On September 2, 2005 7:24:54 PM +0200 Erik Abele [EMAIL PROTECTED] 
wrote:



Yes, infra could say 'no' more often or could simply shut down the
services they don't want to administer. To be honest, I'd be fine  with
this (and its consequences (people/projects leaving, flamewars,
what-have-you)) but since I don't want to discuss this in hundreds of
emails, I'll simply leave and let others take over. No harm done.


In addition to agreeing with everything Erik said, I'll add the following:

Publicity and legal issues can't be neglected or dropped the same way that 
the infrastructure stuff could be (or is by necessity, due to overload).


The effect of letting bad stories fester in the media or ignoring a lawsuit 
is a far greater risk to the foundation than not creating an account the 
second someone submits an account request.  -- justin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The Incubator and Infrastructure

2005-09-02 Thread Leo Simons
Niclas,

On 02-09-2005 17:25, Niclas Hedhman [EMAIL PROTECTED] 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.

In that case you're not coming across too well you know.

What *is* your intention? Are you helping us out here? How?

- LSD



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The Incubator and Infrastructure

2005-09-01 Thread David Crossley
Davanum Srinivas wrote:
 
 Several people on WS-PMC offered to help infra. They were turned down
 as they are not members.

I find that surprising. We are actively encouraging
*committers* to be involved.
http://www.apache.org/dev/infra-volunteer.html

There is plenty that they can do. I am not talking
about satisfying their own project needs, but about
general help. That will free up the other people
to concentrate on stuff that needs tighter permissions.

-David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]