"Trac does not send email unless you list the address in the CC field": update wiki?

[Juan Manuel Palacios]

On Mar 20, 2007, at 2:15 PM, Elias Pipping wrote:

> There's basically these kinds of tickets out there
>
>  * general Macports-base-related tickets
>    * minor annoyances
>    * major feature requests

	The way I see it, "base" tickets are of two subtypes:

1) bug reports, either minor or big;
2) feature requests (enhancements), either minor or big.

	They should go into either a version'd milestone (say, "MacPorts 1.5") 
or into the newly created "Needs developer review" milestone, depending 
on:

*) Is it a feature request? Discussion on this list (and/or on the 
ticket, of course) and consensus should decide what future MacPorts 
release it belongs in, but otherwise it should go into "Needs dev 
review" until there's consensus;
*) Is it a bug? Feel free to add it to a version'd milestone if you 
plan to work on it yourself and fix it; otherwise put it in "Needs dev 
review" and move it to a version'd milestone only after proper 
discussion here (yes, even if the bug is critical, for which we have 
the "Severity" and "Priority" ticket fields, along with good & loud 
ranting ;-)

	All in all, version'd milestones and "Needs dev review" should only 
carry tickets of the "base" component and none others (the only other 
two that currently make sense are "Infrastructure", which is for 
MacOSForge & hosting related issues, and "ports", which we discuss 
below).


>  * ports-related tickets
>    * new ports

	They now have their own milestone.

>    * bugs
>    * updates
>    * requests for new variants/changes to the port

	Lets call the last "miscellaneous enhancements" (request for 
enhancement, RFE).

>
> bugs, updates and feature-/variant-requests are all thrown together 
> into available ports whereas new ports have a separate milestone. that 
> should be changed, i believe. maybe four milestones for that is too 
> many, maybe not.

	Right, we're throwing three different ticket subtypes, all belonging 
to the "ports" component, into a single milestone, and what I would 
like to know is if that combined with proper summary prefixing ("BUG", 
"UPDATE" & "RFE", respectively) is enough and functional... or if 
separate milestones for each subtype are absolutely necessary. I don't 
want to sound like I'm adverse to creating them, I'm not; I just want 
to make sure we're making the right decision here 'cause, one, I don't 
want to spread things too thin (as previously stated) and, two, I 
wouldn't like to see any of us going through the hell of editing 
literally hundreds and hundreds of tickets to adapt to a new layout if 
we ever need to change our roadmap once these milestones are fully in 
use.

	As for filtering tickets in the combined "Available Ports" milestone, 
proper trac searching can be of great help:

http://trac.macports.org/projects/macports/search?q=BUG&ticket=on
http://trac.macports.org/projects/macports/search?q=UPDATE&ticket=on
http://trac.macports.org/projects/macports/search?q=RFE&ticket=on

	To construct these all you need to do is browse to the Search module 
and deselect "Changesets" and "Wiki" and introduce the proper ticket 
prefix in the search field, but suffice it to say that the above URL's 
serve as static links to all the matching results in our database 
(going *all* the way back!). More complex searches (ticket open? 
closed? assigned? etc..) can be performed with the help of the Reports 
module and either an existing report or a custom query, but I readily 
realize the natural filters a roadmap milestone provides can easily be 
of greater help.

	Feedback people, feedback! :-P


-jmpp