On Apr 7, 2005 9:31 AM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > I think the problem I see with that is that if you are making changes to > existing code in the Struts distribution it means that people have to make > a conscious choice to go down a potentially incompatible path. > > I think struts.sf.net works fine for things that truly are extensions, > i.e., things that don't require an updated struts.jar for instance... > But, anything that would require that, like these Ajax-aware tags requires > one existing class be altered, makes it more difficult... > > If I were to finish this up and post it on struts.sf.net (or the Wiki, > same argument) and then people decide to use it, they won't be able to > move to 1.3... well, *theoretically* they couldn't, in this case they > actually probably could, but for something like my setupItems a while back > for instance, they couldn't. They would be relying on ME to upgrade it > for each new Struts version (or prior versions maybe even) or they would > have to do it themselves. > > But, if it was accepted into the Struts project proper, then it would be > dealt with as part of the project, and while I myself still might be > responsible for making sure it works with the next version, I am then > doing so in the context of the larger project.
Before any of us add something to the main project, *all* of us have to feel like it is going to be maintained. If necessary, each of us has to be willing to take on the maintenance of any part of the project ourselves. That doesn't mean we have to write the patches, but it does mean we have to be willing to consider patches the community supplies. Which implies there has to be a community ready, willing, and able to supply patches for us to consider. Before we can commit to new code, we want to see the code in action. We want to know how the community feels about it. We want to know how easy it will be to maintain and patch. And we have to feel like the original coder is going to stick by the product, at least for awhile. When the code is created by someone who is already a committer, we can put it in our own sandbox. Struts-Chain started this way, as did Struts-Shale and Struts-Faces. Other gizmos, like the Nesting Taglibs, Struts EL, the Validator, Tiles, and others, all had their own sites and followers *before* we ever added them to the main project. Once we do add code to the main project, we take it very seriously. We maintain it over time, and if we decide to remove it, we do so by deprecating and replacing over a series of releases. This is what we have always done, and this is what the community expects us to do. Is it hard to get new code into the Struts project? Yes, it is. But peole do it. Craig did it. Don did it. I'm hoping Niall will do it soon with LazyDynaBeans, and that Hubert will do the same. Do most of the components come from committers? Yes, they do. Sometimes they were committers first. And sometimes they made committer afterwards. It's not a coincidence, since if we believe in the code, and the community behind the code, then we tend to believe in the coder too. But, the committers don't ask anyone to do anything that we don't do ourselves. All of us put new components through the sandbox or an external site first. The main difference between a committer and a developer, is that committers are willing to do it ourselves, regardless of whether something is added to the main project or not. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
