+1 But let's not label it the "2.1" branch. Last I knew, we observed the Rules for Revolutionaries
* http://incubator.apache.org/learn/rules-for-revolutionaries.html which says that we should name the branch first, and then decide whether to accept it, or what version to assign, once there is actual code on the table. -Ted. On 8/25/06, Don Brown <[EMAIL PROTECTED]> wrote:
I agree to a degree, however, it is inevitable that a lot of resources that would be used in moving the code forward are absorbed by these "discussions", and generally, the folks with the energy and vision to move forward don't have the patience for drawn out detail discussions. While ideally, there is a healthy balance between diversity and unity of vision, I feel the Struts community is leaning too much towards diversity lately with little unity of vision. The problem is we don't seem to have a shared vision of what Struts 2 is and should be, and we need that shared vision to guide our discussions and propel innovation. When we started the Struts Ti proposal, we did so with the vision of a framework that makes development easier, requires no configuration, and had support for advanced flow management features. If that is still the desired goal, then I think Patrick's Able extensions is our best bet to realizing it. In fact, it was from working closely with Patrick in implementing the first versions of Ti that prompted the closer collaboration movements, culminating in Ted's proposal to combine efforts completely. Should Able go into the code base now? No, I think we should take what we have, get it stable, and get it out there to our users. However, we shouldn't wait to start realizing the Ti vision, so I propose we start the Struts 2.1 branch in Subversion, and seed it with Able. Let 2.1 be a breeding ground for innovative, convention-based code. We need to foster continued, forward-looking development, while stabilizing what we have today. Don Ted Husted wrote: > But, we are the user base too. In practice, a PMC is a working focus > group. Hopefully, we will attract developers from a wide variety of > projects, so that the framework we build will be robust enough to fill > all our varied needs. > > Personally, I think it's a good thing that Patrick writes applications > one way and that Jason writes them a different way. The differences > are our strength. The differences are what make the framework worth > the time and effort it takes to build it. > > -Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
