Page History

...

• pick the issue at hand
• burst of discussion on the list
• secretary captures the salient points
• offers up the document for review
• go back to discussion/capture/review until complete
• a final document then accompanies the resolution and the issue is closed

NOTESThings that can be done to make the process easier to track:

...

• A filter can be created to send all unresolved issues for a release to the dev list

...

• .
• Might be able to setup custom workflow that can help streamline the process once an issue has been earmarked for a release.
• Tagging

...

• issues with multiple components so that an issue is marked with its real category but can also be marked with a meta category like

...

• design

...

• or

...

• best practices

...

• which would allow us to group them in a view and be able to report on them.

...

• Find a way to sync all the bits and pieces in jira and confluence so we have a cohesive view of the work that needs to be done and planned for.

One person might start a discussion but it can be picked up by anyone who has the energy/motivation/time/whatever to finish it. I think what happened with the dev process works just fine. The issue was in JIRA with me assigned, but you had time to post some initial thoughts and I tried to follow up with a document. The issue needs a champion but anyone should be able to carry it to completion because all the information should be clearly visible.

...

• TODO We need a staging artifact repository where the RCs can be placed so that failed RC attempts don't pollute a release artifact repository
• TODO We need a reliable way of moving the successful RC from the staging repository to the release repository. This is an intended feature for the Repository Manager but we may need a stop-gap solution until the Repository Manager is ready for production use.
• TODO We need to ensure that the RC that gets promoted as the release is not rebuilt. At the same time we need to provide a way to identify what version a user is running (be it a RC1, RC2, etc). One solution is to use a build# so that a maven2 version is always made of both a Version + a build number. For example you would have "Maven 2.1 Build # 1353" which would be RC1 and then "Maven 2.1 Build # 1450" which would be RC2 which gets promoted as the 2.1 release.

...