struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
Date Thu, 23 Nov 2006 16:29:56 GMT
On 11/23/06, Ted Husted <husted@apache.org> wrote:
>
> I'd like to see the proposal discuss the alternatives to becoming a
> Struts subproject. A good role for a proposal is to summarize various
> threads. Becoming a subproject seems to be a foregone conclusion of
> the proposal, with no discussion of the alternatives.


Well, yeah, that's what is being _proposed_. We did discuss the options on
the mailing list, more than once, and came to the conclusion that becoming a
Struts sub-project was the right interim step. I don't see that we need to
have the discussion all over again just because the proposal has been put on
the wiki.

In previous threads, Jakarta was mentioned, but not so much the
> Jakarta Commons. Why is it that we are not proposing to move Tiles to
> the Commons, as we did with the Validator, and others?


Sigh. We've had this discussion _lots_ of times already, and we've had
similar discussions over in Commons. Jakarta Commons is not about web
components, and people do not want it to be about web components, which is
why the notion of Jakarta Web Components has been bandied about so much.
Validator makes sense in Commons because it's not tied to the web; the part
that does tie to the web is in Struts, not Validator. I, for one, would not
want to propose Tiles as a Commons component, because I'm almost certain it
would be rejected, and because I would vote against that myself.

Also, Tiles might be able to become a TLP by resolution of the board.
> The situation is not much different than Shale. The incubator is
> charged with "acceptance and oversight of new products submitted or
> proposed to become part of the Foundation". Tiles is already part of
> the foundation.


Yes, Tiles might be able to become a TLP, but it is my perception that the
people involved are not ready for that. It behooves us to provide better
options than either staying in the sandbox or going straight to TLP. That
you bring up Shale is interesting; note that we went through exactly the
same process with Shale as we are now proposing for Tiles. Shale went from
the sandbox to a Struts sub-project first. Only later, once it found its
feet as a sub-project, did it go off to TLP land.

Speaking of the Incubator, we might also note that Incubator podlings
> do have releases.
>
> Even without quantifying it as a "release", given the usual release
> plan, Tiles could still create a tagged test-build. Before deciding
> whether Tiles should be a subproject or not, I think I'd like to see
> the volunteers create a test-build that could be a release if the PMC
> gave the nod.


Why would we introduce a new rule for Tiles that we have never imposed on
other projects coming out of the sandbox?

Moving a code branch out the sandbox is a trivial task. What's not
> trivial is doing everything that's needed to turn a snapshot into a
> potential release.


True. But that has never before been tied to promoting something out of the
sandbox, and I don't think that introducing it in the midst of a proposal,
after most of the discussion has already happened on the lists, is a
productive thing to do.

--
Martin Cooper


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message