Craig McClanahan wrote:
On 4/26/06, Don Brown <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to