...
- 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.
...