You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Tim Colson (tcolson)" <tc...@cisco.com> on 2005/09/13 07:44:55 UTC
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: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Jira maintenance
Posted by Nathan Bubna <nb...@gmail.com>.
just to clarify, i believe Will was referring to all *resolved* bugs
for 1.4 and earlier. the matter of resolved bugs is the context of
the larger conversation
On 9/14/05, Henning P. Schmiedehausen <hp...@intermeta.de> wrote:
> "Will Glass-Husain" <wg...@forio.com> writes:
>
> >Hi,
>
> >Makes sense to close all bugs for 1.2 and earlier. (I'd actually suggest
> >1.4 and earlier).
>
> There are still issues open for 1.4 that are valid for 1.5. E.g. VELOCITY-147
>
> Best regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> 4 - 8 - 15 - 16 - 23 - 42
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Jira maintenance
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Will Glass-Husain" <wg...@forio.com> writes:
>Hi,
>Makes sense to close all bugs for 1.2 and earlier. (I'd actually suggest
>1.4 and earlier).
There are still issues open for 1.4 that are valid for 1.5. E.g. VELOCITY-147
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Jira maintenance
Posted by Will Glass-Husain <wg...@forio.com>.
> i could be ok with closing resolved bugs for 1.3 once 1.5 work starts.
Hasn't 1.5 work already started? Everything that's been done since the 1.4
release is 1.5 work. I see 31 bullets in the changelog for post 1.4 work.
Of course, it's been sporadic so maybe it isn't visible.
http://svn.apache.org/viewcvs.cgi/jakarta/velocity/core/trunk/xdocs/docs/changes.xml?view=markup
WILL
----- Original Message -----
From: "Nathan Bubna" <nb...@gmail.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Tuesday, September 13, 2005 8:53 AM
Subject: Re: Jira maintenance
On 9/13/05, Will Glass-Husain <wg...@forio.com> 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" <nb...@gmail.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> Sent: Tuesday, September 13, 2005 7:24 AM
> Subject: Re: Jira maintenance
>
>
> On 9/12/05, Will Glass-Husain <wg...@forio.com> 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)" <tc...@cisco.com>
> > To: "Velocity Developers List" <ve...@jakarta.apache.org>
> > Cc: "Jeff Turner" <je...@apache.org>
> > 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: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Jira maintenance
Posted by Nathan Bubna <nb...@gmail.com>.
On 9/13/05, Will Glass-Husain <wg...@forio.com> 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" <nb...@gmail.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> Sent: Tuesday, September 13, 2005 7:24 AM
> Subject: Re: Jira maintenance
>
>
> On 9/12/05, Will Glass-Husain <wg...@forio.com> 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)" <tc...@cisco.com>
> > To: "Velocity Developers List" <ve...@jakarta.apache.org>
> > Cc: "Jeff Turner" <je...@apache.org>
> > 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: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Jira maintenance
Posted by Nathan Bubna <nb...@gmail.com>.
On 9/13/05, Will Glass-Husain <wg...@forio.com> wrote:
> I like Mike's idea "mark bugs closed when they're fixed in a public
> release". Seems less arbitary then close after X public releases. A
> release should mean that all enhancements are correct and all bugs are
> really fixed. Otherwise - why release?
>
> The process becomes
> -> "Reporter" creates issue with bug report
> -> "Contributor" marks ASSIGNED, uploads patch
> -> "Committer" commits patch to source code and marks RESOLVED
> -> As part of the release process, all bugs marked with the release version
> number must move to CLOSED.
>
> The last bullet implies that the committer(s) do a review of all bugs and
> make sure they are really resolved. To be safe, the bugs should be closed
> when the release goes "gold". In other words, first release "1.5rc1", then
> if necessary release "1.5rc2". If that release holds water, mark all bugs
> as closed and go to "1.5".
>
> Comments?
works for me. i suppose it's not that big a deal to give reporters
that much time to check up on their bugs once resolved.
> Best,
> WILL
>
> ----- Original Message -----
> From: "Mike Kienenberger" <mk...@gmail.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> Sent: Tuesday, September 13, 2005 8:30 AM
> Subject: Re: Jira maintenance
>
>
> In Cayenne, we mark bugs closed when they're fixed in a public release.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Jira maintenance
Posted by Will Glass-Husain <wg...@forio.com>.
I like Mike's idea "mark bugs closed when they're fixed in a public
release". Seems less arbitary then close after X public releases. A
release should mean that all enhancements are correct and all bugs are
really fixed. Otherwise - why release?
The process becomes
-> "Reporter" creates issue with bug report
-> "Contributor" marks ASSIGNED, uploads patch
-> "Committer" commits patch to source code and marks RESOLVED
-> As part of the release process, all bugs marked with the release version
number must move to CLOSED.
The last bullet implies that the committer(s) do a review of all bugs and
make sure they are really resolved. To be safe, the bugs should be closed
when the release goes "gold". In other words, first release "1.5rc1", then
if necessary release "1.5rc2". If that release holds water, mark all bugs
as closed and go to "1.5".
Comments?
Best,
WILL
----- Original Message -----
From: "Mike Kienenberger" <mk...@gmail.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Tuesday, September 13, 2005 8:30 AM
Subject: Re: Jira maintenance
In Cayenne, we mark bugs closed when they're fixed in a public release.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Jira maintenance
Posted by Mike Kienenberger <mk...@gmail.com>.
In Cayenne, we mark bugs closed when they're fixed in a public release.
On 9/13/05, Will Glass-Husain <wg...@forio.com> 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" <nb...@gmail.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> Sent: Tuesday, September 13, 2005 7:24 AM
> Subject: Re: Jira maintenance
>
>
> On 9/12/05, Will Glass-Husain <wg...@forio.com> 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)" <tc...@cisco.com>
> > To: "Velocity Developers List" <ve...@jakarta.apache.org>
> > Cc: "Jeff Turner" <je...@apache.org>
> > 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: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Jira maintenance
Posted by Will Glass-Husain <wg...@forio.com>.
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" <nb...@gmail.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Tuesday, September 13, 2005 7:24 AM
Subject: Re: Jira maintenance
On 9/12/05, Will Glass-Husain <wg...@forio.com> 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)" <tc...@cisco.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> Cc: "Jeff Turner" <je...@apache.org>
> 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: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Jira maintenance
Posted by Nathan Bubna <nb...@gmail.com>.
On 9/12/05, Will Glass-Husain <wg...@forio.com> 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)" <tc...@cisco.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> Cc: "Jeff Turner" <je...@apache.org>
> 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: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Jira maintenance
Posted by Will Glass-Husain <wg...@forio.com>.
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?
Best,
WILL
----- Original Message -----
From: "Tim Colson (tcolson)" <tc...@cisco.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Cc: "Jeff Turner" <je...@apache.org>
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: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Jira maintenance
Posted by Nathan Bubna <nb...@gmail.com>.
On 9/12/05, Tim Colson (tcolson) <tc...@cisco.com> wrote:
> 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.
cool! thanks, Tim!
> 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.
what does "off" mean? does it mean that all the velocity stuff in
bugzilla disappears? or just that it becomes read-only? i would
prefer the latter. otherwise links to old bugs in mail archives will
be broken. i don't want new data going into bugzilla, but it'd be
nice if old data was still easy to find. of course, it'd be nicer
still to have a sign posted where the old data used to be that tells
where it has been moved to. what's possible here?
> 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.
+1
> 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.
+1 will dvsl get its own project too?
>
> Cheers,
> Timo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org