On 8/21/07, Paul Benedict <[EMAIL PROTECTED]> wrote: > What's the traction on having S2 plugin-only committers? I am referring to a > previous email from Antonio. Just like people sign CLA to write > documentation, I think our plugin development would have a major boost if we > could have plugin-only committers too.
If the question is whether I would vote for someone because he or she has been working on a third-party Struts plugin, then the answer is yes. But that doesn't mean we have to restrict someone to working solely on plugins or a particular plugin. It would be a mistake to consider plugins a lesser form of contribution. Heck, Struts 3, is likely to be just a set of OSGi plugins, a la Eclipse :) Regardless, I think we'd still want to see the code before accepting the plugin into the project. So, someone would still need to setup shop someplace, just like now. We'd also want to have reason to believe that the individual will continue to maintain the plugin over the long term, so we'd want to see some track record of support. I'm not sure how different that would be from what we have today. >From the opposite perspective, if someone wants our blessing before he or she will code and support a plugin, then I'd rather that person were not part of the group. It takes initiative to survive here. If someone wants to make a case for bringing a given plugin into the project (like JSON), and bringing the developers along with it, that's fine with me. We gave credit to the WebWork crew, and, personally, I'm happy to extend credit for work on other open source projects. (People have done the same for me!) Of course, if the IP is not created here from scratch, so we will need to bring those plugins through the incubator. But that doesn't need to be an extended process. Another way to boost plugin development would be to create an umbrella GoogleCode site to host plugins, rather than a separate site for each one, and offer membership to all the Struts committers, as well as any developer with a plugin to commit. If that group then wants to encourage people to discuss those plugins on the Struts mailing list, and help manage the Plugin Repository site, that's fine with me. In the end, an external Plugin group could become a "feeder" mechanism for core Struts plugins and committers. Though, personally, I think trying to host all possible plugins via the Struts projects is a very bad idea. I'm not going to continue to put my own +1 on releases unless I believe each and every plugin in the distribution is being supported by an active member of the group. We might also need to get used to the fact that if a plugin loses support, we may need to archive it. As to independant release cycles, we tried that with Struts 1, people didn't like it, and so we changed back. The leading complaint was keeping track of whether a given plugin release works with a given core release. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
