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