Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
On Nov 25, 2006, at 9:32 AM, Ted Husted wrote: Could we also document the alternative of moving the org.apache.tiles packages *into* the struts2-plugin? The proposal cites three problems: 1 Can't release 2 Not visible 3 Not permanent As part of the Struts2 Plugin, problems 1 and 2 will be solved. The problem I'm most concerned about with this proposal is problem 1. Our main goal here is to find a point where we stop adding revolutionary features and start moving towards a GA release. To me the most urgent visibility problem is that people can't download an actual Tiles release. They have to download a snapshot build. So the Struts 2 plugin and the Shale view handler have to depend on a snapshot release. Other projects, like MyFaces, just depend on Tiles 1.x. My initial goal is to give people a Tiles 2.0.0 that is an Alpha-quality release and I think the other Tiles developers are on the same page. If all we want to do is separate Tiles from the core, then mission accomplished, put the packages back into the plugin. I disagree. If we do that Tiles is not standalone anymore and the mission is no longer accomplished. Tiles 2 currently has no dependencies on Struts and contains no integration code with any other framework. Integration with another framework is provided by the other framework. That's the whole idea of making it standalone. If we put the packages into the plugin it now has an integration layer with Struts 2. When we decide where it will ultimately live we will have to separate the plugin from the core Tiles framework. That means separating codebase, test cases, doc, build files, etc. I want to keep Tiles standalone, graduate so we can release an alpha, then put our focus into knocking out the rest of the issues and deciding where the permanent project will live. Realistically, making Tiles a subproject is not going to suddenly create community interest in the codebase. That didn't happen for the other subprojects, that we later merged back into Struts 1, it really didn't happen for Shale either, and it's unlikely to happen to Tiles. To create community, a codebase needs to stand on its own or be part of a larger umbrella project, like the Commons or the ASF itself. I agree. I don't see this move as building community. It's just a stepping stone on the path to independence. As part of the Struts 2 plugin, other projects, like Shale, and Spring, and WebWork, would be able to make use of Tiles, which is the primary goal. We can make the Tiles plugin as visible as we want it to be, and it will be just as easy to promote Tiles to TLP later, should other developers materialize (or remateralize). Yes, but then the plugin would be part of Tiles. I personally don't want that and I think that goes against the original reason for creating the standalone Tiles project. I'm OK with listing Jakarta Commons as a home for Tiles, as well as a new Jakarta Subproject or even TLP for Web Components. I'm also OK with listing the s2 plugin as an option, even though it's not an option I'm in favor of. But our focus here is not trying to find the permanent home for Tiles. We are intentionally leaving that question open for the time being and trying to move Tiles to a place where it will stabilize. The reason the subproject appeals to me is that we can simply copy the tiles sandbox svn tree out of the sandbox and cut an alpha release. Then we can start trying to answer the bigger questions. Any other path either 1) takes us backwards with regard to independence (struts2-plugin) or 2) requires a whole lot more community-building and red tape before we can move any further (jakarta, TLP, etc.). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
On 11/27/06, Greg Reddin [EMAIL PROTECTED] wrote: To create community, a codebase needs to stand on its own or be part of a larger umbrella project, like the Commons or the ASF itself. I agree. I don't see this move as building community. It's just a stepping stone on the path to independence. The sandbox was suppose to be the stepping stone. The original idea was to separate the Tiles code base so that it could apply for TLP status. * http://wiki.apache.org/struts/TilesTopLevel :) Now, we're asking for a stepping-stone for the stepping-stone. :) Struts is *not* an incubator. We tried the Shale thing as a courtesy to the JSF specification, but it was not our original intention to be a stepping stone for Shale, and there's no reason to make that same blunder with Tiles. If the Tiles group wants to release, then apply to the Jakarta Commons as one it's server-based components, or to the board for a TLP. In the alternative, move the o.a.t package to the plugin, and release it with Struts 2. People used to lug around the entire Struts JAR just to access Tiles. Being able to just snag the plugin is huge improvement over what we have in Struts 1.3. It may not be the final solution, but it is as good an interim solution as an interim subproject. From an infrastructure standpoint, the only and only difference between a subproject and a plugin is that Tiles would not have its own release cycle. As a subproject, it still won't have its own lists or JIRA instance. Anyone interested in Tiles will still have to wade through all the Struts stuff. As a subproject, all Tiles will have is a homepage, and a plugin could have a home page too, if we want. Here's the thing: If all these other projects depend on Tiles, then why are they not contributing? If other people won't contribute to Tiles in the sandbox, they won't contibute to Tiles as a Struts subproject either. If the Tiles group wants to build community, then cut the apron strings and move on. One approach would be to update the TLP proposal and draw up a corresponding Commons Subproject proposal, and invite people from other communites to sign up as a committer to one or the other. If we want other people to contribute, then we should *invite* them to contribute, and stop casting Tiles as a Struts thing. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
Sorry for the rant. I would have just sent the last two paragraphs, but the phone rang, and I pressed the wrong button :( On 11/27/06, Ted Husted [EMAIL PROTECTED] wrote: Here's the thing: If all these other projects depend on Tiles, then why are they not contributing? If other people won't contribute to Tiles in the sandbox, they won't contibute to Tiles as a Struts subproject either. If the Tiles group wants to build community, then cut the apron strings and move on. One approach would be to update the TLP proposal and draw up a corresponding Commons Subproject proposal, and invite people from other communites to sign up as a committer to one or the other. If we want other people to contribute, then we should *invite* them to contribute, and stop casting Tiles as a Struts thing. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
No problem. I just haven't had time to formulate a response yet :-) Greg On Nov 27, 2006, at 2:02 PM, Ted Husted wrote: Sorry for the rant. I would have just sent the last two paragraphs, but the phone rang, and I pressed the wrong button :( On 11/27/06, Ted Husted [EMAIL PROTECTED] wrote: Here's the thing: If all these other projects depend on Tiles, then why are they not contributing? If other people won't contribute to Tiles in the sandbox, they won't contibute to Tiles as a Struts subproject either. If the Tiles group wants to build community, then cut the apron strings and move on. One approach would be to update the TLP proposal and draw up a corresponding Commons Subproject proposal, and invite people from other communites to sign up as a committer to one or the other. If we want other people to contribute, then we should *invite* them to contribute, and stop casting Tiles as a Struts thing. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
On 11/24/06, David H. DeWolf [EMAIL PROTECTED] wrote: For the sake of documentation, I'll go ahead and take some of these (and Ted's) points regarding where to go upon graduation and post them to the wiki. Thanks everyone for your continued input. . . Could we also document the alternative of moving the org.apache.tiles packages *into* the struts2-plugin? The proposal cites three problems: 1 Can't release 2 Not visible 3 Not permanent As part of the Struts2 Plugin, problems 1 and 2 will be solved. Problem 3 is *not* solved by making Tiles a subproject. If anything, it muddies the water, since I don't think anyone believes that a subproject is an acceptable longterm solution. If all we want to do is separate Tiles from the core, then mission accomplished, put the packages back into the plugin. If we want to attract a larger community, then we have to get Tiles out from under the shadow of Struts. Realistically, making Tiles a subproject is not going to suddenly create community interest in the codebase. That didn't happen for the other subprojects, that we later merged back into Struts 1, it really didn't happen for Shale either, and it's unlikely to happen to Tiles. To create community, a codebase needs to stand on its own or be part of a larger umbrella project, like the Commons or the ASF itself. Struts has proven to be a poor umbrella in the past, and there's no reason to believe that would change. As part of the Struts 2 plugin, other projects, like Shale, and Spring, and WebWork, would be able to make use of Tiles, which is the primary goal. We can make the Tiles plugin as visible as we want it to be, and it will be just as easy to promote Tiles to TLP later, should other developers materialize (or remateralize). We would just need to make it clear that Struts 2 is not the only target platform for the Tiles plugin. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
I know I'd like to see Tiles live on its own somewhere other than here. Tiles has forever been associated with Struts, and while the code is now independent of Struts, just being here makes it part of Struts in many people's minds. I'd be +1 for Tiles going TLP, and if that means first going through Jakarta, I also have a binding vote there as well. -- James Mitchell 678.910.8017 On Nov 24, 2006, at 9:51 PM, David H. DeWolf wrote: For the sake of documentation, I'll go ahead and take some of these (and Ted's) points regarding where to go upon graduation and post them to the wiki. Thanks everyone for your continued input. . . David Niall Pemberton wrote: If tiles can achieve the critical mass to become a TLP then IMO that would be the best solution - at this point it looks at least a couple of devs short of that. In the meantime its question of where can it do its growing?. Commons makes less sense to me than staying here since theres definetly already a community here interested in Tiles - in Commons we don't know how interested the community would be and I doubt it would ever match here. Add to that the fact that the 3 interested developers are already Struts developers - but not Commons developers and the fact that tiles resources (repository bugs) are already here staying here for the time being looks like the best option. I can only think of reasons why it would be better for tiles to remain in Struts rather than Commons. If there is a case for moving tiles to Commons, then its yet to be made for me. Making it a Struts2 sub-project seems like a backward step - what would have been the point of emarking on a standalone tiles if the end result is for it to just move from being part of Struts1 to part of Strus2? Again if there are the benefits of doing this then they need to be laid out. I really can't see the point of making alternative suggestions without making the case for them. I can see benefts for tiles being (temporarily) a Struts sub-project - theres an interested community here - the active developers are here - the other developers here all know what tiles is about (to varying degrees) - theres a PMC that knows the software ...and unless someone else makes a better case for an alternative then thats the best option IMO Niall On 11/24/06, Ted Husted [EMAIL PROTECTED] wrote: 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
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
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
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
If tiles can achieve the critical mass to become a TLP then IMO that would be the best solution - at this point it looks at least a couple of devs short of that. In the meantime its question of where can it do its growing?. Commons makes less sense to me than staying here since theres definetly already a community here interested in Tiles - in Commons we don't know how interested the community would be and I doubt it would ever match here. Add to that the fact that the 3 interested developers are already Struts developers - but not Commons developers and the fact that tiles resources (repository bugs) are already here staying here for the time being looks like the best option. I can only think of reasons why it would be better for tiles to remain in Struts rather than Commons. If there is a case for moving tiles to Commons, then its yet to be made for me. Making it a Struts2 sub-project seems like a backward step - what would have been the point of emarking on a standalone tiles if the end result is for it to just move from being part of Struts1 to part of Strus2? Again if there are the benefits of doing this then they need to be laid out. I really can't see the point of making alternative suggestions without making the case for them. I can see benefts for tiles being (temporarily) a Struts sub-project - theres an interested community here - the active developers are here - the other developers here all know what tiles is about (to varying degrees) - theres a PMC that knows the software ...and unless someone else makes a better case for an alternative then thats the best option IMO Niall On 11/24/06, Ted Husted [EMAIL PROTECTED] wrote: 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
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
Antonio Petrelli wrote: David H. DeWolf ha scritto: Please find the Tiles2 graduation proposal draft below. I look forward to your feedback . . . For the record, +1 Myself :) +1, but I think that also Wendy should be put as an active participant, since she helped us with Maven, gave a lot of useful suggestions and made tests. Sure, the original thought was to document the fact that we meet quota, not to exclude anyone. . . the more the merrier. Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
I know I might miss the struts2 release, but I'm going to let this sit at least another day or two since some people haven't had a ton of time to chime in and because of the US holiday this week. . . David David H. DeWolf wrote: Please find the Tiles2 graduation proposal draft below. I look forward to your feedback . . . http://cwiki.apache.org/confluence/display/S2WIKI/Tiles2+Graduation+Proposal David Martin Cooper wrote: Just write up a brief proposal that we can discuss, maybe on the wiki, as Wendy suggested. Once we have that, we can bounce the idea around a bit and then vote on it. IMO, it would be a good idea to include in the proposal a bit about a Struts sub-project not being the intended final home for Tiles but rather an intermediate step in the process of growing up. You could mention options for a final home, but I personally don't feel that we need to decide on that right now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
For the sake of documentation, I'll go ahead and take some of these (and Ted's) points regarding where to go upon graduation and post them to the wiki. Thanks everyone for your continued input. . . David Niall Pemberton wrote: If tiles can achieve the critical mass to become a TLP then IMO that would be the best solution - at this point it looks at least a couple of devs short of that. In the meantime its question of where can it do its growing?. Commons makes less sense to me than staying here since theres definetly already a community here interested in Tiles - in Commons we don't know how interested the community would be and I doubt it would ever match here. Add to that the fact that the 3 interested developers are already Struts developers - but not Commons developers and the fact that tiles resources (repository bugs) are already here staying here for the time being looks like the best option. I can only think of reasons why it would be better for tiles to remain in Struts rather than Commons. If there is a case for moving tiles to Commons, then its yet to be made for me. Making it a Struts2 sub-project seems like a backward step - what would have been the point of emarking on a standalone tiles if the end result is for it to just move from being part of Struts1 to part of Strus2? Again if there are the benefits of doing this then they need to be laid out. I really can't see the point of making alternative suggestions without making the case for them. I can see benefts for tiles being (temporarily) a Struts sub-project - theres an interested community here - the active developers are here - the other developers here all know what tiles is about (to varying degrees) - theres a PMC that knows the software ...and unless someone else makes a better case for an alternative then thats the best option IMO Niall On 11/24/06, Ted Husted [EMAIL PROTECTED] wrote: 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
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
Don Brown ha scritto: +0 with the caveat that its temporary nature is very clearly marked on the Struts site. We just finished fighting off the impression we are a generic umbrella project, and I'd like to not go through that again. Wiki just edited, it is the last sentence in the page. Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
David H. DeWolf ha scritto: Please find the Tiles2 graduation proposal draft below. I look forward to your feedback . . . +1, but I think that also Wendy should be put as an active participant, since she helped us with Maven, gave a lot of useful suggestions and made tests. Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
Please find the Tiles2 graduation proposal draft below. I look forward to your feedback . . . http://cwiki.apache.org/confluence/display/S2WIKI/Tiles2+Graduation+Proposal David Martin Cooper wrote: Just write up a brief proposal that we can discuss, maybe on the wiki, as Wendy suggested. Once we have that, we can bounce the idea around a bit and then vote on it. IMO, it would be a good idea to include in the proposal a bit about a Struts sub-project not being the intended final home for Tiles but rather an intermediate step in the process of growing up. You could mention options for a final home, but I personally don't feel that we need to decide on that right now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
+0 with the caveat that its temporary nature is very clearly marked on the Struts site. We just finished fighting off the impression we are a generic umbrella project, and I'd like to not go through that again. Don David H. DeWolf wrote: Please find the Tiles2 graduation proposal draft below. I look forward to your feedback . . . http://cwiki.apache.org/confluence/display/S2WIKI/Tiles2+Graduation+Proposal David Martin Cooper wrote: Just write up a brief proposal that we can discuss, maybe on the wiki, as Wendy suggested. Once we have that, we can bounce the idea around a bit and then vote on it. IMO, it would be a good idea to include in the proposal a bit about a Struts sub-project not being the intended final home for Tiles but rather an intermediate step in the process of growing up. You could mention options for a final home, but I personally don't feel that we need to decide on that right now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
On Nov 22, 2006, at 12:51 PM, David H. DeWolf wrote: Please find the Tiles2 graduation proposal draft below. I look forward to your feedback . . . http://cwiki.apache.org/confluence/display/S2WIKI/Tiles2+Graduation +Proposal +1 with one clarification. I think the Community Involvement section should either be rewritten or removed. Technically, a release requires three PMC votes, not just committer votes. Since that's an Apache directive not a Struts directive, I'm not sure if it's necessary to even list the requirement. Maybe it should be changed to note the active participants in the project. Am I correct? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
