In Cayenne, we mark bugs closed when they're fixed in a public release. 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). > > 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. > > - 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) > > 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]
