Some of us are clashing on Trac: in one corner, those who keep duplicate tickets and/or set them to appropriate milestones; in the other corner, those (read, only me, I think) who take them out of milestones when encountering them. The way I see it, if the ticket is a duplicate of an "original" one, and said original is already properly milestoned, then what's the benefit of also having the duplicate in the same milestone? And if said original is *not* properly milestoned, then it should be ;-) But that's of course only one side of the ring. What does the other side have to say about it? Regards,... -jmpp
On Jan 17, 2008, at 23:46, Juan Manuel Palacios wrote:
Some of us are clashing on Trac: in one corner, those who keep duplicate tickets and/or set them to appropriate milestones; in the other corner, those (read, only me, I think) who take them out of milestones when encountering them.
The way I see it, if the ticket is a duplicate of an "original" one, and said original is already properly milestoned, then what's the benefit of also having the duplicate in the same milestone? And if said original is *not* properly milestoned, then it should be ;-)
But that's of course only one side of the ring. What does the other side have to say about it?
Why shouldn't all tickets (even duplicate tickets) have the correct milestone?
I agree with Ryan, but are you also saying you also keep them "open"? Is there a reason for having multiple tickets open for the same issue? -Bill On Jan 17, 2008, at 9:51 PM, Ryan Schmidt wrote:
On Jan 17, 2008, at 23:46, Juan Manuel Palacios wrote:
Some of us are clashing on Trac: in one corner, those who keep duplicate tickets and/or set them to appropriate milestones; in the other corner, those (read, only me, I think) who take them out of milestones when encountering them.
The way I see it, if the ticket is a duplicate of an "original" one, and said original is already properly milestoned, then what's the benefit of also having the duplicate in the same milestone? And if said original is *not* properly milestoned, then it should be ;-)
But that's of course only one side of the ring. What does the other side have to say about it?
Why shouldn't all tickets (even duplicate tickets) have the correct milestone?
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist@apple.com 408 862 7337
On Jan 18, 2008, at 1:26 AM, William Siegrist wrote:
I agree with Ryan, but are you also saying you also keep them "open"? Is there a reason for having multiple tickets open for the same issue?
-Bill
No, if they're duplicates then they are closed, already dealt with. But I believe there's no point in either putting them in a milestone or keeping them in it if there's already one ticket there, the "original", that describes the same issue. There's the "original" and the others are just fat, bloat, in my opinion. The Adium team handles the issue by creating a milestone specifically for duplicate tickets, regardless of the program component they were filed against... but I don't think I like that approach too much either. -jmpp
On Jan 17, 2008, at 9:51 PM, Ryan Schmidt wrote:
On Jan 17, 2008, at 23:46, Juan Manuel Palacios wrote:
Some of us are clashing on Trac: in one corner, those who keep duplicate tickets and/or set them to appropriate milestones; in the other corner, those (read, only me, I think) who take them out of milestones when encountering them.
The way I see it, if the ticket is a duplicate of an "original" one, and said original is already properly milestoned, then what's the benefit of also having the duplicate in the same milestone? And if said original is *not* properly milestoned, then it should be ;-)
But that's of course only one side of the ring. What does the other side have to say about it?
Why shouldn't all tickets (even duplicate tickets) have the correct milestone?
On Jan 18, 2008, at 00:28, Juan Manuel Palacios wrote:
On Jan 18, 2008, at 1:26 AM, William Siegrist wrote:
On Jan 17, 2008, at 9:51 PM, Ryan Schmidt wrote:
On Jan 17, 2008, at 23:46, Juan Manuel Palacios wrote:
Some of us are clashing on Trac: in one corner, those who keep duplicate tickets and/or set them to appropriate milestones; in the other corner, those (read, only me, I think) who take them out of milestones when encountering them.
The way I see it, if the ticket is a duplicate of an "original" one, and said original is already properly milestoned, then what's the benefit of also having the duplicate in the same milestone? And if said original is *not* properly milestoned, then it should be ;-)
But that's of course only one side of the ring. What does the other side have to say about it?
Why shouldn't all tickets (even duplicate tickets) have the correct milestone?
I agree with Ryan, but are you also saying you also keep them "open"? Is there a reason for having multiple tickets open for the same issue?
No, if they're duplicates then they are closed, already dealt with.
But I believe there's no point in either putting them in a milestone or keeping them in it if there's already one ticket there, the "original", that describes the same issue. There's the "original" and the others are just fat, bloat, in my opinion.
The Adium team handles the issue by creating a milestone specifically for duplicate tickets, regardless of the program component they were filed against... but I don't think I like that approach too much either.
I think the natural thing to do, the thing that most people would think to do, would be to assign all tickets to their correct milestone, whether they are duplicates or not. If you want duplicates to have no milestone, I'll defer to your portmgr hat, but request that this be documented in the guide. Currently it says nothing about duplicate tickets. Having a "Duplicate Tickets" milestone would certainly make it clear that duplicate tickets should be placed in that milestone. However, I'm not sure I see why it's desirable to have duplicate tickets in a different (or no) milestone.
participants (3)
-
Juan Manuel Palacios
-
Ryan Schmidt
-
William Siegrist