When we invented the Commons, it was not our intention to exclude
"web
components". If we had even suggested such a thing, I doubt that the
Jakarta PMC would have approved our proposal. At the time, we
took the
notion that ASF projects were suppose to be tied to HTTPD very
seriously. Of course, since then, we added many top-level projects
that have little to do with HTTPD. But, that shouldn't mean web
components have suddenly become second-class citizens. I believe
that
the phrase "server-related" in the charter is meant to include web
servers.
Unless and until the Jakarta Commons PMC rejects a proposal from the
Tiles group, I consider it to be a valid alternative to be explored,
and until it's been fully explored, I will consider the proposal to
create a Struts Tiles subproject premature.
Others may think differently, but I am entitled (and even
obliged) to
define what it is required to obtain my vote. (The vote need not be
unanimous, but only a 3/4 majority of the PMC.)
As it stands, the ASF's preferred unit of release is the TLP. If the
Tiles group is not ready to become a TLP, and unwilling to even try
and join the Commons, then I would suggest that Tiles is not
ready to
"graduate".
A third alternative (aside from an independant project) would be to
bring Tiles back into the Struts 2 subproject as part of the Tiles
plugin. If other projects want to use Tiles, they could just grab
the
tiles-plugin.jar and import the appropriate packages. Rather than
fuss
with a separate project or subproject, we could document how to use
the Tiles JAR outside of the Struts 2 environment.
If volunteers from other projects begin to contribute to Tiles, and
want to *build* Tiles without importing the s2 core, then the Tiles
group could then apply for TLP status, either to the board or though
the Incubator. In the meantime, we could continue to handle Tiles
matters on the mailing lists, just as we would for any plugin (or
subproject).
In any event, if it would be helpful, I see no reason why we can't
create tagged builds of Tiles. A build is not a release,
regardless of
whether we call it a "nightly", "snapshot", or "test".
-Ted.
On 11/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On 11/23/06, Ted Husted <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
