[OT] [JOKE] Re: Jakarta: Confederation or Single Project?

[Brian McCallister <mc...@forthillcompany.com>]

Holy war time:

IoC TLP's

public class Log4J implements JakartaAware, LoggingAware
{
	...
}

public class Log4J
{
	public void setJakarta(Jakarta jakarta) { ... }
	public void setLogging(Logging logging) { ... }
}

public class Log4J
{
	public Log4J(Jakarta jakarta, Logging logging) { ... }
}

=)

-Brian

On Dec 19, 2003, at 2:04 PM, Craig R. McClanahan wrote:

> Quoting Harish Krishnaswamy <hk...@comcast.net>:
>
>> 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org