From: Christoph Wickert <christoph.wickert@gm...> - 2012-11-30 11:33:07
Am Montag, den 05.11.2012, 19:37 +0100 schrieb Geoffrey De Belie:
> Hi all,
> Is the page http://wiki.lxde.org/en/index.php?title=Release_Management
> still up-to-date? If not, could you please add your name/remove
> someone who isn't member of the release management team anymore?
this page is the result of a session we had at LinuxTag and it is still
up to date, at least for the process. Unfortunately nobody ever followed
the it when I offered to take over release management.
Not sure about the people involved, but I am still volunteering to step
up, if we really can agree on something.
From: Martin Bagge / brother <brother@bs...> - 2013-01-07 08:32:00
-----BEGIN PGP SIGNED MESSAGE-----
On 2012-11-05 19:37, Geoffrey De Belie wrote:
> Is the page
> http://wiki.lxde.org/en/index.php?title=Release_Management still
> up-to-date? If not, could you please add your name/remove someone
> who isn't member of the release management team anymore?
A long overdue thing to look at indeed.
Lately (last six months or more) I have been doing the releases and
mostly it has been libfm and pcmanfm where lstranger have been the
A rough release process would look something like this:
1. develop stuff
2. develop stuff
3. talk about having a release
4. develop stuff
5. settle on a good release date
6. freeze strings and sync files for translation
7. call for translations
8. develop stuff
(7 and 8 happens in parallel ofc)
9. test build release
10. tag and build release
11. upload file to sourceforge
12. write release statement on blog
13. unfreeze strings
14. GOTO 1
In my opinion this process lacks some parts but still works.
the main problem here is that we do not announce releases intentions
public enough (I have done so at some points in time but that's more
luck than plan).
It works because libfm and pcmanfm has been a one man show, if it
would be two or three (or more) active developers I do not think this
workflow would work.
I have no strong opinions in this matter, other than the ones I have
stressed before - release early, release often. I am all for planning
but using strict dates I do not believe in.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----