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 <[EMAIL PROTECTED]> 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: <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
