Release Engineering

hmmm reduced to a simple redmine task :-)

I do agree, this will give us the best security.

Depending on Cloph, an alternative is that I do e.g. the pootle extract for one release, and signing for another. Whatever works best for Cloph, will also work for me, I just need a notice a couple of days in advance, so I can remove all other priority stuff.

Just so it does not get forgotten: certificate and vm access are outstanding

Plan is that Jan does a release on his own this week and Cloph is there as fallback, so we see if/what things are missing

So far I am done (only missing Announce mails, which might be better if cloph does, since I am offline friday-monday incl.)

First a big thank to Cloph, for not getting irritated over my problems (mostly caused because I followed the documents to the letter).

Second, I would like to:
- Update the release documentation, with Cloph overseeing the result (but do not know where to update the html)
- Do a second RC, just to make sure I got everything correct

While I did the release, I noted all my "challenges", I add them here, so we can discuss how to handle them (ignore them, because I trust the document too much, is a perfectly legal option).

a) No documentation of when to use Tag / Branch and the naming
It is not documented when we use Tagging or Branching and how the naming is done. The release doc should have a start chapter about that.

I got a commit message wrong, because the naming was not clear to me (in commits we use e.g. 5.1.1.1 and 5.1.1.1.0+)

b) Having a dedicated release vm (or a corner on a build box)
I (as many) have limited upload bandwidth, so e.g. uploading the source tar balls took 3 hours.
Having a dedicated vm (or a corner on a build box), would saving "git clone, git submodule update" time, and also make sure it was more consistent.

c) Backup for Cloph.
I can now do the release tagging/branching etc. BUT Cloph is also
- BZ admin (not a problem as there are others)
- Windows build (Access to a build vm, would solve my problem)
- Linux build (see point b)

d) Getting the sources.
Cd $core_repo/translations, dictionaries, helpcontent2 is empty, no description on how to fill it

DO NOT DO "git clone git://anongit.freedesktop.org/libreoffice/translations"

git submodule update --init dictionaries
helpcontent2
translations
git checkout branch in translations, not important in other modules

e) Extract translations from pootle --
sudo su - www-data starts a sh not a bash, so the commands do not work

workaround start bash.

f) Scripts are all in html.
The scripts are all defined in HTML, but it kind of silly, that every release manager (for every release) has to make scripts from the html page.

I suggest we make a dev-tools/scripts/release and keep them there (some of them, might need to be slightly modified)

g) Certificate
As Cloph politely expressed it "it is somewhat clear that a certificate is needed when signing" :-)

The documents silently assumes you know when it must be available. Again a good reason to have a fixed release vm/corner

I do understand that first time is the difficult one, but I would really like to make sure, we are better prepared

open actions:
- decide to update documents (who)
- give jani access to a place to release build windows/linux
- decide on scripts

Update from ESC meeting (and "staff" meeting afterward.

Norbert argued why I cannot build releases on a vm accessible from the internet, due to the certificate, and he is right. So I will instead find a way to upscale my internet connection.

However, this means I need to build windows/linux locally, I have a
- Windows 8.1 vm
- Ubuntu 14.04 vm
Is that enough ?

I need the acconfig.input for the platforms.
and maybe other instructions.

Hi guys, not sure if I should comment here or open a new Redmine task (apologies in advance!), but it seems we’ve slipped somewhere in the release process, as many commits to helpcontent2 that were only intended to the master branch are showing up in the 5.1 builds. Please see http://listarchives.libreoffice.org/global/l10n/msg09671.html

Thanks and sorry if this is not the right place for me to bring this up!

Jan will do a 2nd round (incl. branch, last time only was tagging), his experiences will be factored into the documentation
On comment #5 (thanks Adolfo!) that should be fixed now with rc3

Update as preparation for G++ tomorrow:

First a big thank to Cloph, for not getting irritated over my problems (mostly caused because I followed the documents to the letter).

Second, I would like to:
- Update the release documentation, with Cloph overseeing the result (but do not know where to update the html)
- Do a second RC, just to make sure I got everything correct

While I did the release, I noted all my "challenges", I add them here, so we can discuss how to handle them (ignore them, because I trust the document too much, is a perfectly legal option).

1) No documentation of when to use Tag / Branch and the naming

Explanation from Cloph:
Every version has it's own branch.
We have libreoffice-5-1 branch where all 5-1-x branches will be
created from, each 5.1.x release has its own branch. there is
libreoffice-5-0-0 branch, libreoffice-5-0-1 branch, ....
libreoffice-5-0-5 branch.

from libreoffice-5-1-1 branch rc1 as well as rc2 are created, while at
the same time stuff for the upcoming 5.1.2 gets submitted to the
libreoffice-5-1 branch.

From this libreoffice-5-1-1-1 is a branch as well, why do tagging to the branch point ?

2) Should we make a introductory release doc, that covers the general items
- when to Tagging / branching ?
- when to update pootle templates
- when to create new pootle project

I got a commit message wrong, because the naming was not clear to me (in commits we use e.g. 5.1.1.1 and 5.1.1.1.0+)

3) Having a dedicated release vm (or a corner on a build box)
I got a .ova file at FOSDEM, that is good to build windows ?
We need to secure I have access to the cent-os box.
Any other builds/things I need to do ?

4) Getting the sources.
Cd $core_repo/translations, dictionaries, helpcontent2 is empty, no description on how to fill it
-- Update doc.

DO NOT DO "git clone git://anongit.freedesktop.org/libreoffice/translations"

git submodule update --init dictionaries
helpcontent2
translations
git checkout branch in translations, not important in other modules

5) Extract translations from pootle --
sudo su - www-data starts a sh not a bash, so the commands do not work
---- update doc.

workaround start bash.

6) Scripts are all in html.
The scripts are all defined in HTML, but it kind of silly, that every release manager (for every release) has to make scripts from the html page.

I suggest we make a dev-tools/scripts/release and keep them there (some of them, might need to be slightly modified)

7) Certificate
As Cloph politely expressed it "it is somewhat clear that a certificate is needed when signing" :-)

The documents silently assumes you know when it must be available. Again a good reason to have a fixed release vm/corner

Norbert had some strong opinions on removing the certificate again (because my machine, like most machines, have a potential internet connection)
--- Update doc.