Roadmap does not provide direction

[rhwood@…]

The Trac Roadmap is currently either misused or underused or both. While allowing us to categorize tickets by type, it should also function as a roadmap--allowing a new developer to get a quick sense of the direction for the project, and to provide guidance for project members needing to prioritize activities.

See also  http://lists.macosforge.org/pipermail/macports-dev/2008-April/004926.html

[wsiegrist@…]

I duped the ticket I submitted about this (#15112). I am taking the ticket and will be working with portmgr to come up with some changes for milestones/roadmap.

[wsiegrist@…]

I would like to use Milestones for their actual purpose, which is to assign tickets to future releases so we can see how close we are to a given version. I propose to remove the existing "category" milestones and setup milestones for 1.6.1, 1.7.0, 1.8.0, and 2.0. The 2.0 milestone would basically serve as a bucket for tickets that are to be worked on far in the future. People can then nominate tickets for a particular release by putting them in a milestone. If people disagree, then the milestone is changed or removed.

This of course only applies to tickets against base, or whatever else goes into a release. Tickets against portfiles should not have a milestone or a version, since those fields deal with base releases.

The version field should mark the most recent version that is affected by the ticket. An enhancement ticket should not have a version number, but it should have a milestone. A defect ticket should have both set.

Please provide feedback here in a comment. Once we come to a final set of guidelines, I'll update the Guide and perform the necessary ticket changes.

[raimue@…]

I generally like the idea to make a better roadmap using milestones. I wouldn't make "2.0" a milestone for "later", because there could be tickets which need a great change and therefore are not to be considered for 1.x releases. We should better make a separate milestone named like "later", "unconsidered", "unscheduled", "open".

For tickets against ports we should use the 'Component' field set to "ports" and not assign a milestone. For the difference between "Port Bugs", "Port Enhancements", "Port Updates" etc. we could set the 'Type' field accordingly (defect, enhancement, update, submission, request).

But this is not ideal as it could result in invalid combinations (like Component "base" and Type "request"). So as an alternative – if we bother about those invalid combinations at all – we could instead use the 'Keyword' field to reflect the state of the ticket by adding one of defect, enhancement, update, submission, request to it.

We should create  reports as a replacement for the currently used milestones to get a quick overview over tickets for a specific component/type.

[wsiegrist@…]

I don't follow your statement about 2.0 versus Later. But the name of the milestone for tickets scheduled far in the future is just cosmetic. We agree that a milestone should exist for those kinds of tickets.

There is already a "ports" component. The ticket type for ports that dont build/fetch should be "defect" and for version bumps or new ports, it should be "enhancement". I dont think we need to complicate it more than this. The title of the ticket should clarify what the ticket is about.

[paulbeard@…]

I would like to see a release schedule, say every 90 days or so, and whatever is ready gets rolled out. I suspect there is a lot stuff piling up in the mythical 1.7 release. It might be a good motivator to get that would and see how much progress has been made since 1.6. The release process is pretty opaque to those of who are not on the -dev list and I'm sure the project needs a lot of uninformed observers there ;-) better to post progress reports out to the user community.

All this is predicated on whether or not you want people using releases or pulling from the trunk, as the broken 1.6 release get older and older.

[rhwood@…]

Replying to paulbeard@gmail.com:

The release process is pretty opaque to those of who are not on the -dev list and I'm sure the project needs a lot of uninformed observers there ;-) better to post progress reports out to the user community.

It seems to pretty opaque to me on the -dev list even.

[wsiegrist@…]

Reassigning to portmgr for review in light of new management/release plans. Should I go through and relabel tickets with release milestones instead of the meta-categories they have now?

[anonymous]

Milestone Website & Documentation deleted

[jmr@…]

We're now using milestones to target tickets at releases, and I just got rid of the non-milestone milestones (Port Bugs, Port Requests, Port Updates, Port Enhancements, Port Submissions, Website & Documentation) and replaced them with ticket types where the entire sense was not already covered by the component and the existing ticket types.