You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2010/05/07 16:39:05 UTC
RFC: Issue tracker treatment of patches.
I've never been a fan of the PATCH issue type present in our tracker. While
the other issue types (TASK, DEFECT, ENHANCEMENT, FEATURE) tell you
something about the problem that needs a-fixin', PATCH tells you only that
someone has proposed some code change. But for what?
So in the ViewVC project I switched do a slightly different method for
tracking patches, which goes as follows:
- never ever use the PATCH issue type. Instead, use the type appropriate
for what the patch proposes to change about the code. Is it fixing a
DEFECT? Adding a new FEATURE? etc.
- for issues that have a patch associated with them, record a "patch"
keyword. This still allows you to query "all issues with patches"
just as easily as querying issue_type=PATCH, and does so (again)
without losing that valuable information about the real problem.
I'd like to move to this methodology in our own tracker. Like, today.
Because the changes are reversible, I'll probably just go for it later this
afternoon, after seeking some favor in IRC and after popping off this email.
And of course, I'll update any related docs we may have on the website (for
the public, or Patch Manager instructions, etc.).
Anybody object?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: RFC: Issue tracker treatment of patches.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Okay, this change has been made. Please refrain from using the PATCH issue
tracker type from now on. If you have a patch to post to a new tracker
item, create the item as a DEFECT or ENHANCEMENT or FEATURE, attach the
patch, and add the 'patch' keyword to the issue.
Thanks all!
-- With love, and just trying to stay afloat in the issue tracker,
C-Mike
C. Michael Pilato wrote:
> I've never been a fan of the PATCH issue type present in our tracker. While
> the other issue types (TASK, DEFECT, ENHANCEMENT, FEATURE) tell you
> something about the problem that needs a-fixin', PATCH tells you only that
> someone has proposed some code change. But for what?
>
> So in the ViewVC project I switched do a slightly different method for
> tracking patches, which goes as follows:
>
> - never ever use the PATCH issue type. Instead, use the type appropriate
> for what the patch proposes to change about the code. Is it fixing a
> DEFECT? Adding a new FEATURE? etc.
>
> - for issues that have a patch associated with them, record a "patch"
> keyword. This still allows you to query "all issues with patches"
> just as easily as querying issue_type=PATCH, and does so (again)
> without losing that valuable information about the real problem.
>
> I'd like to move to this methodology in our own tracker. Like, today.
> Because the changes are reversible, I'll probably just go for it later this
> afternoon, after seeking some favor in IRC and after popping off this email.
> And of course, I'll update any related docs we may have on the website (for
> the public, or Patch Manager instructions, etc.).
>
> Anybody object?
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: RFC: Issue tracker treatment of patches.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Okay, this change has been made. Please refrain from using the PATCH issue
tracker type from now on. If you have a patch to post to a new tracker
item, create the item as a DEFECT or ENHANCEMENT or FEATURE, attach the
patch, and add the 'patch' keyword to the issue.
Thanks all!
-- With love, and just trying to stay afloat in the issue tracker,
C-Mike
C. Michael Pilato wrote:
> I've never been a fan of the PATCH issue type present in our tracker. While
> the other issue types (TASK, DEFECT, ENHANCEMENT, FEATURE) tell you
> something about the problem that needs a-fixin', PATCH tells you only that
> someone has proposed some code change. But for what?
>
> So in the ViewVC project I switched do a slightly different method for
> tracking patches, which goes as follows:
>
> - never ever use the PATCH issue type. Instead, use the type appropriate
> for what the patch proposes to change about the code. Is it fixing a
> DEFECT? Adding a new FEATURE? etc.
>
> - for issues that have a patch associated with them, record a "patch"
> keyword. This still allows you to query "all issues with patches"
> just as easily as querying issue_type=PATCH, and does so (again)
> without losing that valuable information about the real problem.
>
> I'd like to move to this methodology in our own tracker. Like, today.
> Because the changes are reversible, I'll probably just go for it later this
> afternoon, after seeking some favor in IRC and after popping off this email.
> And of course, I'll update any related docs we may have on the website (for
> the public, or Patch Manager instructions, etc.).
>
> Anybody object?
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: RFC: Issue tracker treatment of patches.
Posted by Craig L Russell <cr...@oracle.com>.
Hi C. Michael,
As a developer of non-svn stuff and a user of svn, not a developer of
svn, I support your notion that PATCH doesn't have any meaning.
I might also make the same comment about TASK. But that's another
issue for another day.
Craig
On May 7, 2010, at 9:39 AM, C. Michael Pilato wrote:
> I've never been a fan of the PATCH issue type present in our
> tracker. While
> the other issue types (TASK, DEFECT, ENHANCEMENT, FEATURE) tell you
> something about the problem that needs a-fixin', PATCH tells you
> only that
> someone has proposed some code change. But for what?
>
> So in the ViewVC project I switched do a slightly different method for
> tracking patches, which goes as follows:
>
> - never ever use the PATCH issue type. Instead, use the type
> appropriate
> for what the patch proposes to change about the code. Is it
> fixing a
> DEFECT? Adding a new FEATURE? etc.
>
> - for issues that have a patch associated with them, record a "patch"
> keyword. This still allows you to query "all issues with patches"
> just as easily as querying issue_type=PATCH, and does so (again)
> without losing that valuable information about the real problem.
>
> I'd like to move to this methodology in our own tracker. Like, today.
> Because the changes are reversible, I'll probably just go for it
> later this
> afternoon, after seeking some favor in IRC and after popping off
> this email.
> And of course, I'll update any related docs we may have on the
> website (for
> the public, or Patch Manager instructions, etc.).
>
> Anybody object?
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On
> Demand
>
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
Re: RFC: Issue tracker treatment of patches.
Posted by Stefan Sperling <st...@elego.de>.
On Fri, May 07, 2010 at 12:39:05PM -0400, C. Michael Pilato wrote:
> I've never been a fan of the PATCH issue type present in our tracker. While
> the other issue types (TASK, DEFECT, ENHANCEMENT, FEATURE) tell you
> something about the problem that needs a-fixin', PATCH tells you only that
> someone has proposed some code change. But for what?
>
> So in the ViewVC project I switched do a slightly different method for
> tracking patches, which goes as follows:
>
> - never ever use the PATCH issue type. Instead, use the type appropriate
> for what the patch proposes to change about the code. Is it fixing a
> DEFECT? Adding a new FEATURE? etc.
>
> - for issues that have a patch associated with them, record a "patch"
> keyword. This still allows you to query "all issues with patches"
> just as easily as querying issue_type=PATCH, and does so (again)
> without losing that valuable information about the real problem.
>
> I'd like to move to this methodology in our own tracker. Like, today.
> Because the changes are reversible, I'll probably just go for it later this
> afternoon, after seeking some favor in IRC and after popping off this email.
> And of course, I'll update any related docs we may have on the website (for
> the public, or Patch Manager instructions, etc.).
+1, this makes a lot of sense.
Stefan