21 Jan
2012
21 Jan
'12
9:40 a.m.
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!