Learn about DokuWiki
Learn about DokuWiki
The Release Management Team, as the name suggests, takes care of organizing the whole release process and prepare the release packages.
| Adrian Lang from Berlin
I would like to coordinate the release team and take substantial part in the work we have to do.
| Guy Brand from Strasbourg
I'd gladly take over a part of the needed work in the release team.
| Andreas Gohr from Berlin
I handle things that need access to the DokuWiki server and of course help with setting up the team. I'd love to leave the management of the team to someone else though.
Here's how the Zimbra people do it:
They use bugzilla for bugs and feature requests. These bugs are assigned to (or taken by, I don't know) people responsible for solving the bug or planning the implementation of the feature request. A bug is confirmed through testing, then in development, than resolved as fixed or unfixable or worksforme and then verified (through their QA-department). A feature request is taken into account by counting votes for it. The head of development takes a look at the feature requests with the most votes and this feature gets a higher priority than other features.
All finished bugs are targeted to the next release.
After some time it's feature-freeze time and all feature requests “in progress” are targeted to the next release. Then the plan for the next release (beta, beta2, beta3, rc1, rc2, GA) is made. If a feature request “in progress” cannot be finished, it's slotted to the next release.
When the Zimbra release team thinks, “it's right”, the beta phase is exited into the release candidate-phase, where only bugs are squashed, no feature is altered or added.
After some time, the release gets GA (globally available) and makes it to the download page.
Now something brilliant: They have this product management site (http://pm.zimbra.com), that queries the bugzilla and automatically shows finished bugs, embedded feature requests etc. and thus creates the changelog. Important changes (like the ones Andi marked in his changelogs) are then transported to an official PDF-document available on downloading the release.
I think, that this bug and release management is brilliant, productive and very professional and we should follow that as a guideline. I don't know my way around github's bug management that well. Perhaps someone could answer, if the described bug management and this product management site could be possible using github.
If not, we could move the bug managment to bugzilla (or whatever else, Mantis comes to mind…) and speak with the guys of the admin team about it. (Hey! Just remembered, I'm one of them :) )
– Dennis Ploeger, 2010-10-07 20:24
Bummer! Somehow I forgot, that you people are working with flyspray. Sorry. So, what about actively using the release planning feature of flyspray?
– Dennis Ploeger, 2010-10-08 07:35
Actually, we are using it: http://bugs.dokuwiki.org/index.php?do=roadmap&project=1, just currently there are no open tasks. — adrianlang 2010/10/08 09:53