You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <te...@gmail.com> on 2006/04/26 19:23:21 UTC
How to keep feature changes on the front burner (Re: This has gone too far.)
On 4/26/06, Don Brown <mr...@twdata.org> wrote:
> One of our big problems in the past is bugzilla tickets would be filed,
> patches added, and they'd be ignored for months, even years.
Patches that propose new features or significant feature changes, yes.
Patches that fix a bug in an existing feature, not so much. We've
always applied every known bugfix before a release.
Back in the 1.1 era, we were very busy with extracting components for
the commons, meanwhile the features requests flowed in, as the
popularity of the framework grew. The features list grew to the point
that we can't see the forest for the trees anymore. We've had a "help
wanted" sign up for a volunteer to "normalize" the feature request for
years, but there haven't been any takers.
One strange phenomonen is that some of the feature request patches
have been filed by committers, but never applied. I guess sometimes we
wonder if another committer will "second" the feature. Of course,
these tickets are swallowed up by all the others filed from years
back.
I notice that HTTPD keeps a running tally about some proposed changes
in the status file. Not unlike what we've started to do with the
"rough spots" page.
----
* If the parent process dies, should the remaining child processes
"gracefully" self-terminate. Or maybe we should make it a runtime
option, or have a concept of 2 parent processes (one being a
"hot spare").
See: Message-ID: <3C...@Golux.Com>
Self-destruct: Ken, Martin, Lars
Not self-destruct: BrianP, Ian, Cliff, BillS
Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd
/* The below was a concept on *how* to handle the problem */
Have 2 parents: +1: jim
-1: Justin, wrowe, rederpj, nd
+0: Lars, Martin (while standing by, could it do
something useful?)
----
I could see this technique working well to summarze many of the
development discussion we have, most recently the cancel button issue.
I also wonder if this could be a technique that we could use to
discuss some features before placing then on the feature roadmap.
Personally, if I want the feature I'm just going to commit it and see
if anyone squawks :), but other committers may be more conservative
than me :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: How to keep feature changes on the front burner (Re: This has gone too far.)
Posted by Craig McClanahan <cr...@apache.org>.
On 4/26/06, Don Brown <mr...@twdata.org> wrote:
>
> Craig McClanahan wrote:
> > On 4/26/06, Don Brown <mr...@twdata.org> wrote:
> >> I'd like to see tickets become the ultimate tracker, including
> collecting
> >> votes. I see it working this way:
> >>
> >> - any significant change requires a ticket
> >> - a committer reviews the ticket and decides on a fix version or
> rejects
> >> it outright
> >> - discussion ensues on the ticket, _not_ on the dev list
> >> - a vote is called for on the ticket if necessary
> >> - the release manager must resolve or move the ticket before rolling
> a
> >> release
> >>
> >> This approach allows for considerable debate, however ensures the
> ticket
> >> will ultimately be dealt with in some fashion.
> >> I agree Struts has been very good about fixing bugs, however, we need
> to
> >> extend that same courtesy to other tickets.
> >>
> >> I know not all agree my philosphy, but I think a ticket requires a
> clear
> >> decision on the part of the committers. If it
> >> is to be accepted, give it a fix version. If we think it is
> interesting,
> >> but aren't willing to commit to it, mark it
> >> TBD or Future. If we don't agree, reject it. What we've missed is the
> >> first step: giving it a fix version, leaving all
> >> the enhancement tickets to wallow around, waiting for attention.
> >>
> >> WebWork has been very good about following this approach, and I think
> it
> >> is something we should adopt.
> >
> >
> > I can buy into this in general, but do not think we want to completely
> give
> > up on lazy consensus either -- it should be fine for a committer to go
> ahead
> > and commit a change (at least up to a certain size -- judgement call
> here)
> > without waiting for another committer to agree. If there is objection
> > later, these things can generally be backed out.
>
> Sorry, I didn't mean to imply we were removing lazy consensus.
Didn't think so, but just wanted to make sure.
Tickets can be opened, fix version assigned, and closed
> in the same day. They still will be subject to a review by the release
> manager at release, however. I'm just saying we
> should be using tickets to track these changes and give a clear place for
> their discussion and later reference.
+1.
Don
Craig
Re: How to keep feature changes on the front burner (Re: This has
gone too far.)
Posted by Don Brown <mr...@twdata.org>.
Craig McClanahan wrote:
> On 4/26/06, Don Brown <mr...@twdata.org> wrote:
>> I'd like to see tickets become the ultimate tracker, including collecting
>> votes. I see it working this way:
>>
>> - any significant change requires a ticket
>> - a committer reviews the ticket and decides on a fix version or rejects
>> it outright
>> - discussion ensues on the ticket, _not_ on the dev list
>> - a vote is called for on the ticket if necessary
>> - the release manager must resolve or move the ticket before rolling a
>> release
>>
>> This approach allows for considerable debate, however ensures the ticket
>> will ultimately be dealt with in some fashion.
>> I agree Struts has been very good about fixing bugs, however, we need to
>> extend that same courtesy to other tickets.
>>
>> I know not all agree my philosphy, but I think a ticket requires a clear
>> decision on the part of the committers. If it
>> is to be accepted, give it a fix version. If we think it is interesting,
>> but aren't willing to commit to it, mark it
>> TBD or Future. If we don't agree, reject it. What we've missed is the
>> first step: giving it a fix version, leaving all
>> the enhancement tickets to wallow around, waiting for attention.
>>
>> WebWork has been very good about following this approach, and I think it
>> is something we should adopt.
>
>
> I can buy into this in general, but do not think we want to completely give
> up on lazy consensus either -- it should be fine for a committer to go ahead
> and commit a change (at least up to a certain size -- judgement call here)
> without waiting for another committer to agree. If there is objection
> later, these things can generally be backed out.
Sorry, I didn't mean to imply we were removing lazy consensus. Tickets can be opened, fix version assigned, and closed
in the same day. They still will be subject to a review by the release manager at release, however. I'm just saying we
should be using tickets to track these changes and give a clear place for their discussion and later reference.
Don
> Now that we're switching to JIRA, I look at filing issues from another
> "constructively lazy" perspective as well. File issues for anything that
> you will want listed in the release notes for the next release, and then tag
> them with the fix version when appropriate. No more tediously scanning
> commit emails :-).
>
> Don
>
>
> Craig
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: How to keep feature changes on the front burner (Re: This has gone too far.)
Posted by Craig McClanahan <cr...@apache.org>.
On 4/26/06, Don Brown <mr...@twdata.org> wrote:
>
> I'd like to see tickets become the ultimate tracker, including collecting
> votes. I see it working this way:
>
> - any significant change requires a ticket
> - a committer reviews the ticket and decides on a fix version or rejects
> it outright
> - discussion ensues on the ticket, _not_ on the dev list
> - a vote is called for on the ticket if necessary
> - the release manager must resolve or move the ticket before rolling a
> release
>
> This approach allows for considerable debate, however ensures the ticket
> will ultimately be dealt with in some fashion.
> I agree Struts has been very good about fixing bugs, however, we need to
> extend that same courtesy to other tickets.
>
> I know not all agree my philosphy, but I think a ticket requires a clear
> decision on the part of the committers. If it
> is to be accepted, give it a fix version. If we think it is interesting,
> but aren't willing to commit to it, mark it
> TBD or Future. If we don't agree, reject it. What we've missed is the
> first step: giving it a fix version, leaving all
> the enhancement tickets to wallow around, waiting for attention.
>
> WebWork has been very good about following this approach, and I think it
> is something we should adopt.
I can buy into this in general, but do not think we want to completely give
up on lazy consensus either -- it should be fine for a committer to go ahead
and commit a change (at least up to a certain size -- judgement call here)
without waiting for another committer to agree. If there is objection
later, these things can generally be backed out.
Now that we're switching to JIRA, I look at filing issues from another
"constructively lazy" perspective as well. File issues for anything that
you will want listed in the release notes for the next release, and then tag
them with the fix version when appropriate. No more tediously scanning
commit emails :-).
Don
Craig
Re: How to keep feature changes on the front burner (Re: This has
gone too far.)
Posted by Don Brown <mr...@twdata.org>.
I'd like to see tickets become the ultimate tracker, including collecting votes. I see it working this way:
- any significant change requires a ticket
- a committer reviews the ticket and decides on a fix version or rejects it outright
- discussion ensues on the ticket, _not_ on the dev list
- a vote is called for on the ticket if necessary
- the release manager must resolve or move the ticket before rolling a release
This approach allows for considerable debate, however ensures the ticket will ultimately be dealt with in some fashion.
I agree Struts has been very good about fixing bugs, however, we need to extend that same courtesy to other tickets.
I know not all agree my philosphy, but I think a ticket requires a clear decision on the part of the committers. If it
is to be accepted, give it a fix version. If we think it is interesting, but aren't willing to commit to it, mark it
TBD or Future. If we don't agree, reject it. What we've missed is the first step: giving it a fix version, leaving all
the enhancement tickets to wallow around, waiting for attention.
WebWork has been very good about following this approach, and I think it is something we should adopt.
Don
Ted Husted wrote:
> On 4/26/06, Don Brown <mr...@twdata.org> wrote:
>> One of our big problems in the past is bugzilla tickets would be filed,
>> patches added, and they'd be ignored for months, even years.
>
> Patches that propose new features or significant feature changes, yes.
> Patches that fix a bug in an existing feature, not so much. We've
> always applied every known bugfix before a release.
>
> Back in the 1.1 era, we were very busy with extracting components for
> the commons, meanwhile the features requests flowed in, as the
> popularity of the framework grew. The features list grew to the point
> that we can't see the forest for the trees anymore. We've had a "help
> wanted" sign up for a volunteer to "normalize" the feature request for
> years, but there haven't been any takers.
>
> One strange phenomonen is that some of the feature request patches
> have been filed by committers, but never applied. I guess sometimes we
> wonder if another committer will "second" the feature. Of course,
> these tickets are swallowed up by all the others filed from years
> back.
>
> I notice that HTTPD keeps a running tally about some proposed changes
> in the status file. Not unlike what we've started to do with the
> "rough spots" page.
> ----
>
> * If the parent process dies, should the remaining child processes
> "gracefully" self-terminate. Or maybe we should make it a runtime
> option, or have a concept of 2 parent processes (one being a
> "hot spare").
> See: Message-ID: <3C...@Golux.Com>
>
> Self-destruct: Ken, Martin, Lars
> Not self-destruct: BrianP, Ian, Cliff, BillS
> Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd
>
> /* The below was a concept on *how* to handle the problem */
> Have 2 parents: +1: jim
> -1: Justin, wrowe, rederpj, nd
> +0: Lars, Martin (while standing by, could it do
> something useful?)
>
> ----
>
> I could see this technique working well to summarze many of the
> development discussion we have, most recently the cancel button issue.
>
> I also wonder if this could be a technique that we could use to
> discuss some features before placing then on the feature roadmap.
> Personally, if I want the feature I'm just going to commit it and see
> if anyone squawks :), but other committers may be more conservative
> than me :)
>
> -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