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. 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
