Release Management

From LXDE.org
Revision as of 13:52, 11 June 2010 by Cwickert (talk | contribs) (revisited release process based on our talks at Linuxtag 2010.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

In order to maintain stability and compatibility all releases must follow a clearly defined release process. This helps us to maintain quality of the LXDE components and avoids erroneous releases that cause problems for LXDE's users. Please support the LXDE release engineering by testing the source code of components, filing bugs and coding on LXDE.

Who

The release team currently consists of a number of continuous contributors and package maintainers of distributions offering LXDE including:

  • Andrew Lee (Debian)
  • Andrea (OpenSuse)
  • brother (Translation coordinator)
  • Christoph Wickert (Fedora)
  • PCMan (Core Developer)
  • Marty Jack (Core Developer)
  • Please complete the list

How

Policies

  • LXDE aims at keeping the dependencies between components low. Nevertheless speed and the usage of low resources are other priorities of the LXDE project. Sometimes there are components dependent on each other. The release team aims to release dependent components together.

Workflow

  1. When a developer is about to release a new version of a component, he sends out an announcement to the lxde mailing list
  2. The release manager takes a quick look at the code and confirms that it fulfills the release criteria and is ready for testing.
    1. The release manager sends out a call for testing to the mailing list and freezes the code. Only bugfixes are allowed to go in.
  3. The translation coordinator checks the strings for obvious spelling mistakes and consistency.
    1. The translation coordinator sends out a call for translations to the LXDE translation list and announces a string freeze. New strings must not be added without permission of the translation coordinator.
  4. Package maintainers test the code. If they like, they do a test release in the development branch of their distribution, e.g. Debian Experimental or Fedora Rawhide. Errors should be reported on the mailing list and/or in the bug tracker. If everything works as expected, this should be reported on the mailing list.
  5. The release manager should watch the bugtracker for new bug reports and coordinate the fixes with the developers.
  6. The translation coordinator takes care of translation process.
  7. After one week of testing the release manager and the translation coordinator decide whether the new release can be published based on the feedback from the mailing list, the number of bugs in the bugtracker and the status of the translations.
    1. If there are known bugs, the release manager will encourage the developers to fix them.
    2. If translations are incomplete, the translation coordinator sends out a nag mail to the translation mailing list and/or the translators directly.
  8. If everything is fine the release manager tags the code in git and releases a tarball.
  9. The release is announced on the mailing list and in the blog.
  10. The freeze is lifted.

based on proposal at the LXDE developer mailing list.

Releases

Support

You would like to support the release team. Please join us testing new releases or untested code. Put down your name below and components, distributions or other relevant info you would like to help with. To file bugs you encounter please use the bug tracker here: http://sourceforge.net/tracker/?group_id=180858

Please add your name and info here. (in alphabetic order)

  • Mario Behling mb@mariobehling.de, release team support, lxtask, pcmanfm, tests

Communicate

To gather people and resources and enable better communication we have set up the some communication channels:

  1. A Dev Mailinglist for the LXDE Project used by the release team
  2. Please join us also in the LXDE contributors channel at irc.oftc.net #lxde

Links