21 Jan
2012
21 Jan
'12
9:53 a.m.
On 01/21/2012 03:40 AM, Vincent Massol wrote:
Hi,
On Jan 20, 2012, at 6:29 PM, Marius Dumitru Florea wrote:
From the release plans:
* Mark the agent offline
* Install Jenkins agent's key in github account
* Copy manager's .gitconfig profile
* Install GPG key
There's also the reverse process at the end of the release, included by
Marius in step (7)
Some of it could be automated, sure, I'll work on that.
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
This is done already, the push-release script notifies if there are any
open issues before marking the versions as released, but it's not
enough. The RM will have to check each issue and decide if it should
have been closed or it must be moved. Normally there shouldn't be that
many issues, for some releases I actually didn't have this problem at all.
- 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
One step that I didn't yet manage to get working is setting up
gpg-agent; I still have to watch the build to see when the tag signing
takes place to enter my key passphrase.
- For (7): This could be easily automated I think
It's supposed to be already, but for 3.4M1 the report generated
automatically was wrong because the previous version was still 3.2, not
3.3 (something I forgot to update when releasing 3.3 and which could be
introduced in the release script).
- For (8): The announcement email can be easily
automated, based on (5)
WDYT?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/