Proposal: Start the Struts 2.1 branch (was Re: The importance of defaults)

[Don Brown <mr...@twdata.org>]

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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Proposal: Start the Struts 2.1 branch (was Re: The importance of defaults)

[Don Brown <mr...@twdata.org>]

Fine - I propose the branch be named "Able".

Don

Ted Husted wrote:
> +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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Proposal: Start the Struts 2.1 branch (was Re: The importance of defaults)

[Ted Husted <hu...@apache.org>]

+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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org