Trac Ticketing guidelines

[Ryan Schmidt]

On Jul 15, 2007, at 04:44, Juan Manuel Palacios wrote:

>>> 	-) Expected: for most reports on port build failures, users are  
>>> free to *expect* these to be fixed;
>>
>> I always felt this name was odd. To me, it implies a sort of  
>> indifference to the bug: "we expect it'll get fixed sooner or later."
>>
>> Colloquy's Trac simply defines these as "highest", "high",  
>> "normal", "low", "lowest" (defaulting of course to "normal"). This  
>> seems much clearer and perhaps more useful than our current system.
>
> 	I agree with Ryan and you here, but then with Ryan again: I think  
> "high", "normal" and "low" should suffice for most (if not all) our  
> needs, while also sticking to self-explanatory names (I didn't  
> write the current priorities, I also said "wha...?" when first  
> becoming acquainted with our trac installation ;-). When you have  
> both "highest" and "high", how is what's put in each determined? We  
> want to keep this as simple as possible (but not one bit simpler,  
> as Albert once said).
>
> 	So I'll see about creating the new priorities and what will happen  
> to existing tickets with the priorities I'll delete. We can later  
> on add highest and lowest if need be, but I would discourage that.

Related: I'm not sure why we have both a priority and a severity. I'd  
say we only need one or the other, not both.


>> Feature Requests => Base Enhancements
>> Base Bugs (currently missing?)
>
>
> 	We currently have three milestones meant to group ticket  
> submissions against MacPorts sources:
>
> 1) MacPorts x.y: release specific, where stuff that has been agreed  
> to be worked on for the x.y release should go. I think this  
> milestone is clearly defined.
> 2) Needs developer review: tickets detailing either bugs that can't  
> be reproduced or with no agreed on fix, or enhancements/new  
> features that spark controversy. They can be moved to the release  
> specific milestone once consensus is reached *and* a committer  
> agrees to stand behind it to do the leg work. I think this  
> milestone is also clearly defined, but the protocol to get tickets  
> out of it might be a bit flaky and therefore loosely enforced,  
> suggestions accepted.
> 3) Feature Requests: I agree we need to refine this. I like the  
> "Base Enhancement" & "Base Bugs" idea to group tickets against  
> MacPorts sources that spark no controversy (that is, not in "Needs  
> developer review") but have no man power to do the leg work (so as  
> to keep the release specific milestones clean of stuff that will  
> simply gather dust). Two problems I have with the proposed  
> approach, though: I'd really love it if we could group these two  
> fine ideas in just a single milestone (simplicity is golden!) that  
> conveys the idea of "Will be worked on later"; and based on that,  
> I'd like to use a name other than "Base", as some users are likely  
> to not know what that means. Can you help me come up with a  
> suitable name? I'm a bit sleepy already ;-)

I think the appropriate word would be "infrastructure."

I still have a problem with "MacPorts x.y", "Feature Requests" and  
"Needs developer review".

To be analogous with what we have for ports, we should have  
"Infrastructure Bugs" and "Infrastructure Enhancements". These would  
cover both bugs and enhancements that need developer review and those  
that don't. Do we really need a separate "Needs developer review"  
milestone?

The "MacPorts x.y" milestones also give me problems because I don't  
think the person reporting the bug is in a good position to determine  
what version of MacPorts their bug should be assigned to be fixed in.

We need to decide if we're using "Milestone" as a milestone or as a  
category. We seem to be moving to using it as a category, in which  
case "MacPorts x.y" categories don't make sense to me. Unless it is  
for use by developers who have just fixed something, to indicate what  
version of MacPorts they fixed it in. But that seems to be  
overloading this select box with two meanings, which I don't like.


>>>  *) Version: fine as it is now, but maybe a good addition is  
>>> explaining that this field is irrelevant in some cases (like when  
>>> filing tickets for the guide), whereas it's crucial in some  
>>> others (a bug report against MacPorts sources);
>>>
>>
>> A possible improvement, although more work, would be to add  
>> "release" as the new default, and "trunk". When tagging 1.5.1, the  
>> "release" version would be renamed "1.5.0" and a new "release"  
>> version created.
>
> 	I don't think I fully understand what you're suggesting. Only two  
> versions? We should definitely encourage users to always upgrade to  
> the latest release 'cause we haven't broken backwards compatibility  
> or anything, so no need to keep anyone back; even more now after my  
> dp2mp-move work, which changed so many strings and paths and  
> therefore might make debugging older versions harder. To that  
> effect, I've removed all versions up to 1.5.0 and included 1.6.0 to  
> stay always on "release" and "trunk".

But but but but but... Oh, I see. You can only select 1.5.0 and 1.6.0  
for new tickets, but existing tickets that used earlier versions  
still show those versions. This is good. I wouldn't want to lose this  
information.

I still don't think it's a good idea to remove any of the older  
versions, though. Definitely keep the 1.4.x versions, since 1.5. was  
*just* released and people who aren't in the habit of running  
selfupdate all the time will still be running 1.4.x. And if they run  
into a problem -- perhaps even with the update to 1.5.0 -- they'll  
want to file a bug, and either won't, because their version isn't in  
the menu, and then we won't learn about the problem, or they will,  
but will (by necessity) select the wrong version, which will in turn  
confuse us.