On 9/13/05, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > Hi, > > Makes sense to close all bugs for 1.2 and earlier. (I'd actually suggest > 1.4 and earlier).
i could be ok with closing resolved bugs for 1.3 once 1.5 work starts. the point is that if reporters don't close their bugs after they've been resolved, the thing that makes the bugs "age out" of the queue should be new versions/releases. > But what about new bugs? When in the following typical process do we mark > "CLOSED". > > -> "Reporter" creates issue with bug report > -> "Contributor" marks ASSIGNED then uploads patch > -> "Committer" commits patch to source code > > When do we mark RESOLVED and when CLOSED? It'd be nice to have a policy. > Two options > > Step 1: Committer marks RESOLVED. > Step 2: Reporter verifies bug fix and marks CLOSED. If no action within a > period of time, Committer marks CLOSED. > > This is common internal issue tracking. My worry is that given the diverse > set of reporters, it seems unlikely they'll consistently close issues. this is good, but rather than " period of time", i would say "<x> number of new final releases". > - or - > > Step 1: Contributor uploads patch and marks RESOLVED/FIXED > Step 2: Committer reviews patch and suggests changes (marking REOPEN) or > commits (marking it CLOSED) -1 this seems unintuitive and uncommon. > WILL > > > ----- Original Message ----- > From: "Nathan Bubna" <[EMAIL PROTECTED]> > To: "Velocity Developers List" <[email protected]> > Sent: Tuesday, September 13, 2005 7:24 AM > Subject: Re: Jira maintenance > > > On 9/12/05, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > > Tim, > > > > Kudos for pushing the JIRA thing through. I'm excited about this. > > > > Question to the community. How should we treat "RESOLVED" vs "CLOSED"? > > In > > a team bug reporting environment, the bug fixer is supposed to mark the > > bug > > resolved and the original reporter is supposed to check it and mark it > > closed. Does this work in a diverse community? Or should we just > > automatically "close" bugs once a suitable testing time has passed? > > my preference would be to close resolved bugs referring to anything > resolved two releases ago. of course, reporters can still close them > earlier, but if they don't, i think anything resolved more than one > release ago can be considered sufficiently tested. in other words, > all resolved bugs referring to 1.2 issues and before should be closed. > > > Best, > > WILL > > > > > > ----- Original Message ----- > > From: "Tim Colson (tcolson)" <[EMAIL PROTECTED]> > > To: "Velocity Developers List" <[email protected]> > > Cc: "Jeff Turner" <[EMAIL PROTECTED]> > > Sent: Monday, September 12, 2005 10:44 PM > > Subject: Jira maintenance > > > > > > Hey gang - > > > > So the Jira instance now has Velocity bugs in it... but it looks like > > there needs to be some cleanup done. I can work on that, but want to run > > stuff by here. > > > > I asked Infra how we would request turning off Bugzilla (I didn't ask > > them to turn it off, just "how".) I assume we'll want to direct people > > to 'one' place for issue tracking, and that Jira will be that place very > > very soon. > > > > Hey Shinobu -- Jeff said you need to sign up for a jira account...but, > > uh, I see an account in Jira, so maybe you already created it. At any > > rate, I added you to the velocity-developers group. > > > > Versions -- man, there are a lot of them. Most need to be marked as > > "released", some archived, others perhaps deleted (1.0b1, 1.0b2, 1.0b3 > > -- a quick search, none of them seem to be associated with issues). > > > > I assume we'll want to have 1.5 as unreleased and <1.5 marked as > > released. I suggest we stick 1.6 and 2.0 in the list as well, so we can > > "schedule" bugs/features/improvements for those versions and that way > > the "roadmap" will be clearer for what's on tap for 1.5, 1.6 and beyond. > > > > There are a ton of "resolved" but not "closed" issues... I'll start > > looking at those too so we can get things a bit cleaned up. > > > > Velocity Tools --> I think we should create a separate project like Jeff > > suggested for "VELTOOLS" and move relevant issues over because the two > > projects have separate release schedules and versions. > > > > > > Cheers, > > Timo > > > > --------------------------------------------------------------------- > > 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] > > > > > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
