struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Bubna" <nbu...@gmail.com>
Subject Re: [tiles2] Tiles TLP and Dimensions incubation
Date Fri, 01 Dec 2006 16:54:11 GMT
in my continuing quest to redefine the concept of "umbrella" in Apache-land....

On 12/1/06, Martin Cooper <martinc@apache.org> wrote:
> On 12/1/06, Antonio Petrelli <apetrelli@apache.org> wrote:
> >
> > Craig McClanahan ha scritto:
> > > The Dimensions code is going to have to go through
> > > the Incubator -- even though its likely that this can go very quickly,
> > > there
> > > is no reason to mess up the progress of the Tiles TLP proposal by
> > > trying to
> > > do them together.
> >
> > Hi Craig, when I wrote "at the same time" I did not mean "together".
> > Since probably Dimensions will become a subproject of Tiles TLP
>
>
> I know this has been said by others before, but let me make it very clear:
> The ASF board does not like "umbrella" projects at all, and would most
> likely not approve Tiles as a TLP if it "smelled" of forthcoming
> sub-projects before it even got off the ground.

actually, we were able to take Velocityto TLP with both existing
subprojects and the smell of forthcoming ones.  this was done with
much clarification, restriction, and debate on what constitutes an
acceptable "subproject".  the key difference is that Velocity will not
be a "bucket" project such as Jakarta or db.apache.org that exists to
group projects who share a conceptual space, but whose code and
community are unconnected.   instead, Velocity aims to be a true
"umbrella" where all the Velocity subprojects (spokes of the umbrella)
are truly sub-ordinate.   this means their code and community are
invested in the core Velocity template engine (the center pole) and do
not function without it.   the difference between bucket and umbrella
is crucial to building a healthy, shared community.

other significant differences are that non of the sub-projects get
their own mailing list or svn permissions.  that would fragment the
community.

> The reason that some people do not want Tiles to live on as a sub-project
> within Struts is one of the same reasons that Shale went out on its own;
> sub-projects are a sign that a project is moving in the wrong direction;
> that is, in a direction that is not favoured by the ASF Board, and for good
> reasons. Struts has been moving, and continues to move, in a direction that
> eliminates the notion of sub-projects, the only exception being the two
> versions of the Struts framework itself.

i really think this is throwing out the baby with the bathwater.  just
because the sub-project things has been done poorly, doesn't mean that
it deserves to be eliminated.  i would hope that the board's
acceptance of Velocity and its subprojects as a TLP shows recognition
that it can be done right.

> If Dimensions would ultimately be merged into Tiles, that is one thing, and
> that might be fine. If, however, you are thinking that Dimensions would live
> as a "similar concept but separate framework" to Tiles, but within the same
> TLP, that is quite another thing, and not something I would like to see, not
> to mention the ASF Board.

agreed.  conceptual association is totally insufficient grounds for
shared community.

> So, in short, we should purge the notion of sub-projecs from our minds,
> whichever top-level project we are thinking of, and work on the basis that
> they should not exist.

no thanks.

> --
> Martin Cooper
>
>
> , I
> > thought that probably it was appropriate to wait until it is estabilished.
> > I read this:
> >
> > http://incubator.apache.org/incubation/Incubation_Policy.html#Sponsor
> >
> > <snip>
> > A Sponsor SHALL be either:
> > * the Board of the Apache Software Foundation;
> > * a Top Level Project (TLP) within the Apache Software Foundation (where
> > the TLP considers the Candidate to be a suitable sub-project); or
> > * the Incubator PMC.
> > </snip>
> >
> > Antonio
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message