Hi, On Jan 20, 2012, at 6:29 PM, Marius Dumitru Florea wrote:
> Hi devs, > > Vincent asked me to write down the time I spend doing the release so > that we can see what part of the release process needs to be improved. Thanks Marius. > Here's the result: > > (1) Stabilize the build, making sure all tests pass on CI: up to 4 days > (2) Update translations: ~15min (lots of unsignificant changes that > have to be reviewed and ignored) > (3) Set up the release agent: ~10min > (4) Release on Jira, checking opened issues for partial commits, > moving or splitting issues: ~30min (it really depends on how many > issues have the "Fix Version/s" set to the released version and are > not yet closed) > (5) Write the release notes: from 2h to a full day (the relatively > easy part is scanning closed Jira issues for new features, upgrades, > important bugfixes, migration or backward compatibility problems; then > you have to push developers to document the new features and the > migration problems that they have introduced -- this takes longer) > (6) Maven release: ~2h (if everything goes smoothly, otherwise you > maybe have to spend an additional 1h to fix cyclic dependencies or bad > dependency versions) > (7) Collect Clirr report and clean up the release agent: ~10min > (8) Paper work (announcements/news): ~1h 30min > > As you can see the most time consuming is: > > * stabilizing the build -> committers should check the CI after they commit > * writing the release notes -> committers should document their work > on XWiki.org before the release day > I think we can define 2 separate steps: A - Prepare the release: (1), (4), (5) B - Do the release: (2), (3), (4), (6), (7), (8) We need to find a way to make A faster by spreading the load IMO. Some brainstorming ideas: - For (1): Commits are done on a staging Git repo and are "copied" to the main git repo only if the full build succeeds (including functional tests). If it fails a mail is sent to the committer to tell him his commit didn't make it. Or something like that. - For (2): This can be semi-automated by creating a maven plugin that gets the data from l10n and applies it locally. The user just needs to git commit/push the changes done on his workspace (we need this for a manual visual review and for git credentials). - For (3): I don't know enough what the 10mn are for. I'm pretty sure we can easily reduce this to 10 seconds (the time to log) - For (4): We could imagine an automated script that would look for issues not closed for a given release and send mail to the assignee/mailing list to ask for closing/moving them out - For (5): We could imagine adding a "documentation URL" field in JIRA that is mandatory for "New feature/Improvements" issues and a custom workflow that doesn't allowing closing such issues if it's not filled. We can then imagine a script on xwiki.org to generate the release notes by using a template and by taking all issues from jira. It would use the documentation field to create links automatically too. This script would also send emails to all devs that are assignees of issues asking them to review the page for their issues. - For (6): Nothing much, already automated - For (7): This could be easily automated I think - For (8): The announcement email can be easily automated, based on (5) WDYT? Thanks -Vincent > Thanks, > Marius > > P.S.: Kudos to Sergiu and Caleb for the (semi-)automated release script! _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
