Hi Greg, I agree that we should encourage people to use the "fix version" field more carefully. I think we need to agree on how we use "fix version". How about going through the existing "fix version" tagged issues instead of just removing the tag? I do think that the tagged issues represent overall more pressing issues than the non-tagged.
Cheers, Max On Thu, Feb 25, 2016 at 10:21 AM, Robert Metzger <rmetz...@apache.org> wrote: > Hi Greg, > > I agree with you that the "fix version" field for unresolved issues is > probably used by issue creators to express their wish for fast resolution. > I also saw some cases where issues were reopened. > > I agree with your suggestion to clear the "fix version" field once 1.0.0 > has been released. > > On Mon, Feb 22, 2016 at 4:43 PM, Greg Hogan <c...@greghogan.com> wrote: > >> Hi, >> >> With 1.0.0 imminent there are 112 tickets with a "fix version" of 1.0.0, >> the earliest from 2014. From the ticket logs it looks like we typically >> bump the fix version once the target release has passed. Would it be better >> to wait to assign a fix version until achieving some combination of >> severity, acceptance, and imminence? >> >> For example, a new feature might go unscheduled until a pull request is >> available, whereas a blocker is by definition intended for the next >> release. >> >> A corollary would be to unschedule all open / in progress / reopened >> tickets once their "fix version" has been released. This would present a >> clean slate for the next round of commits. >> >> Greg >>
