Quoting Harish Krishnaswamy <[EMAIL PROTECTED]>:

> Thanks Craig, this is elaborate, informative and puts the issue in my
> perspective. May be this 
> should be put on the website too somewhere.
> 
> Here are my inferences so far...
> 
> <inferences>
> ASF is a group of projects administered by the Apache board members. The
> board delegates certain 
> responsibilities over to the PMCs of the individual projects while still
> maintaining the authority 
> and management responsibilities. The PMC is responsible for a wholesome code
> and community of the 
> project it oversees but does not have the authority to recognize new
> projects.
> 
> Jakarta started out as a single project for a web container and has grown
> into a foundation of 
> projects in itself without sufficient administration/organization.
> </inferences>
> 

Waiting for the bureacracy to be created first is kind of antithetical to the
way most open source developers think :-).

> Here are my thoughts distilled from a lot others'...
> 
> * I think the projects at ASF should be classified in some way (preferably by
> technology like we 
> have now for xml, db etc.) into umbrella projects. All projects piled
> together at the top level 
> would not convey very well. This is where Jakarta would need redefinition.
> Seems like the inital 
> motivation, server side web development, is a good fit. And that would mean
> some reshuffling.

The problem with "graph shaped" (single inheritance) hierarchies is that
sometimes a single project fits more than one place.  For example, where do you
put Cocoon?  It's clearly a thing that fits into an "XML Technologies" sort of
place.  It's also a thing that clearly fits into a "server site technologies"
sort of place.  The answer that Cocoon chose (the right one, IMHO) was to be a
separate TLP that is *linked* to both of those technology's web sites.

But, the more fundamental principle is that the legal organization of the ASF
need not have anything at all to do with how websites are organized and how
projects are made visible.

> * I think each umbrella project or each project within could have a PMC and
> each project should 
> maintain a PMC membership of atleast 51% of its committers to sustain.

That's pretty much the way that Jakarta works now (we've focused on expanding
the PMC membership over the last year to ensure coverage from all the
subprojects).  But, as a Jakarta PMC member, it's still a daunting thought to
be held responsible for oversight of all the code, and all the releases, across
all of Jakarta.  It's hard enough for me, for example, just to stay current on
the three projects I watch and try to participate in (Commons, Struts, Tomcat).
 I'm pretty clueless about what the Tapestry folks are doing, yet *I* need to
approve releases?

Having Tapestry committers on the PMC helps, but isn't sufficient.

> * I think the website should match the organizational structure to avoid
> confusion.

I don't agree.  The website(s) should be focused around making it easy for users
to  find out what Apache projects might have products that are relevant to
their needs.  The internal project organization is an implementation detail.

> * I think the board should classify the newly adopted projects. Projects that
> churn out of existing 
> projects should be brought back to the board for classification at the time
> of creating new CVS 
> repositories.
> * Each umbrella could have a commons and a sandbox to share and play.
> * There could be a top level commons to house cross-umbrella components.
> 
> It seems like what we now have is pretty much in good shape and only means
> that the following 
> actions take place...
> 
> * Reorganize Jakarta (and may be others??)

The interesting question is what Jakarta becomes after the subprojects that want
to become TLPs do so.  I suspect that keeping it as a brand is likely to be
helpful, but the brand has been pretty muddled too (is it "Apache Struts" or
"Jakarta Struts"?  Depends on which book title you read :-), and the earlier
perceptions that Jakarta had for high quality server side Java code is starting
to slip.

> * Enforce project level PMC membership
> 

IMHO, it's just not good enough to satisfy the oversight requirements delegated
to the PMCs by the ASF Board.

> Just my thoughts.
> 
> Regards,
> Harish
> 

Craig


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

Reply via email to