At BoostCon last year, we had a discussion about the Trac system. One of the things that we discussed was the fact that the "Patches" tag in Trac was really a bad way to label things. Don't get me wrong - patches are a good thing. However, if a submitted patch fixes a problem, it should be categorized as a "bug report" with a fix attached. And if a patch adds new functionality, it should be categorized as a "feature request" with a proposed implementation attached. The conclusion that was reached at the end of the discussion was that we wanted to get rid of the "Patches" label for Trac tickets, and to move all the existing patches to either "Bugs" or "Feature Requests". I am proposing that this happen immediately after the release of version 1.39 - or immediately after BoostCon, say. What do people think? -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
Marshall Clow wrote:
At BoostCon last year, we had a discussion about the Trac system. One of the things that we discussed was the fact that the "Patches" tag in Trac was really a bad way to label things.
Don't get me wrong - patches are a good thing. However, if a submitted patch fixes a problem, it should be categorized as a "bug report" with a fix attached. And if a patch adds new functionality, it should be categorized as a "feature request" with a proposed implementation attached.
The conclusion that was reached at the end of the discussion was that we wanted to get rid of the "Patches" label for Trac tickets, and to move all the existing patches to either "Bugs" or "Feature Requests".
I am proposing that this happen immediately after the release of version 1.39 - or immediately after BoostCon, say.
What do people think?
I am no sure this is good idea. Patches should be explicitly marked, and further, should be given priority treatment -- and mixing them with Bug/Feature Request will make it hard to even see what is patch. - Volodya
At 8:56 PM +0400 4/8/09, Vladimir Prus wrote:
Marshall Clow wrote:
Don't get me wrong - patches are a good thing. However, if a submitted patch fixes a problem, it should be categorized as a "bug report" with a fix attached. And if a patch adds new functionality, it should be categorized as a "feature request" with a proposed implementation attached.
The conclusion that was reached at the end of the discussion was that we wanted to get rid of the "Patches" label for Trac tickets, and to move all the existing patches to either "Bugs" or "Feature Requests".
I am proposing that this happen immediately after the release of version 1.39 - or immediately after BoostCon, say.
What do people think?
I am no sure this is good idea. Patches should be explicitly marked, and further, should be given priority treatment -- and mixing them with Bug/Feature Request will make it hard to even see what is patch.
Patches are _not_ being given priority treatment now. There are about 75 tickets marked as 'Patches' in Trac now. 15 were opened in 2009 32 were opened in 2008 26 were opened in 2007 2 were opened in 2006 Here's an example: <https://svn.boost.org/trac/boost/ticket/827> opened Feb 2007. It's a patch to remove an unused variable in date-time. I don't have a problem with some way of marking a ticket that has an attached patch. But I don't think that "Patch" tag is the way to do it. It hides other, more useful information. -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
participants (2)
-
Marshall Clow -
Vladimir Prus