On 4/26/06, Don Brown <[EMAIL PROTECTED]> wrote: > > 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.
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
