Difference between revisions of "Release Management"

From LXDE.org
Jump to: navigation, search
(revisited release process based on our talks at Linuxtag 2010.)
 
m (Not Spam)
 
(12 intermediate revisions by 6 users not shown)
Line 14: Line 14:
 
==How==
 
==How==
  
===Policies===
+
===Release criteria===
* 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.
+
* Releases must cleanly compile into binaries.
 +
* Releases must not break [[#Dependencies |dependencies]].
 +
** If a release introduces incompatible changes (ABI, API or configuration), its dependencies must be updated and released as well.
 +
* Developers should indicate incompatible API changes in a library such as libfm or menu-cache should be indicated through a change of the SO name.
 +
* Releases must be able to install cleanly
  
 
===Workflow===
 
===Workflow===
Line 23: Line 27:
 
## The release manager sends out a call for testing to the mailing list and freezes the code. Only bugfixes are allowed to go in.
 
## The release manager sends out a call for testing to the mailing list and freezes the code. Only bugfixes are allowed to go in.
 
# The translation coordinator checks the strings for obvious spelling mistakes and consistency.
 
# The translation coordinator checks the strings for obvious spelling mistakes and consistency.
## The translation coordinator sends out a call for translations to the [http://mailinglist.lxde.org/cgi-bin/mailman/listinfo/translation LXDE translation list] and announces a string freeze. New strings must not be added without permission of the translation coordinator.
+
## The translation coordinator sends out a call for translations to the [https://lists.sourceforge.net/lists/listinfo/lxde-i18n LXDE translation list] and announces a string freeze. New strings must not be added without permission of the translation coordinator.
 +
# The [[Status_of_LXDE_Components|Component status page is updated]]
 
# 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.
 
# 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.
 
# The release manager should watch the bugtracker for new bug reports and coordinate the fixes with the developers.
 
# The release manager should watch the bugtracker for new bug reports and coordinate the fixes with the developers.
Line 36: Line 41:
 
based on [http://article.gmane.org/gmane.comp.desktop.lxde.devel/1186| proposal at the LXDE developer mailing list.]
 
based on [http://article.gmane.org/gmane.comp.desktop.lxde.devel/1186| proposal at the LXDE developer mailing list.]
  
==Releases==
+
===Dependencies===
 +
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.
  
===Support===
+
The following components are known to impact others:
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
+
* menu-cache: libfm, lxpanel, lxlauncher
 
+
* libfm: pcmanfm
Please add your name and info here. (in alphabetic order)
+
* lxsession: lxappearance, lxinput
* [[User: Mario Behling|Mario Behling]] mb@mariobehling.de, release team support, lxtask, pcmanfm, tests
+
* lxsession: lxsession-edit
 +
* lxmenu-data: lxlauncher, lxpanel
 +
* pcmanfm: lxde-common (configuration only)
 +
* lxpanel: lxde-common (configuration only)
 +
* openbox: lxde-common (configuration only)
  
 
==Communicate==
 
==Communicate==
 
To gather people and resources and enable better communication we have set up the some communication channels:
 
To gather people and resources and enable better communication we have set up the some communication channels:
 
# A [https://lists.sourceforge.net/lists/listinfo/lxde-list Dev Mailinglist for the LXDE Project used by the release team]
 
# A [https://lists.sourceforge.net/lists/listinfo/lxde-list Dev Mailinglist for the LXDE Project used by the release team]
 +
# A [https://lists.sourceforge.net/lists/listinfo/lxde-i18n translation related mailing list used for discussions about context and actual phrasing of the translatable content]
 
# Please join us also in the LXDE contributors channel at irc.oftc.net #lxde
 
# Please join us also in the LXDE contributors channel at irc.oftc.net #lxde
  
Line 52: Line 63:
 
* LXDE Bug tracker: http://sourceforge.net/tracker/?group_id=180858
 
* LXDE Bug tracker: http://sourceforge.net/tracker/?group_id=180858
  
[[Category:LXDE]]
+
[[Category:Development]]
 
[[Category:Projects]]
 
[[Category:Projects]]
 +
 +
[[fr:Gestion des sorties]]

Latest revision as of 15:43, 8 November 2016

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

Release criteria

  • Releases must cleanly compile into binaries.
  • Releases must not break dependencies.
    • If a release introduces incompatible changes (ABI, API or configuration), its dependencies must be updated and released as well.
  • Developers should indicate incompatible API changes in a library such as libfm or menu-cache should be indicated through a change of the SO name.
  • Releases must be able to install cleanly

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. The Component status page is updated
  5. 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.
  6. The release manager should watch the bugtracker for new bug reports and coordinate the fixes with the developers.
  7. The translation coordinator takes care of translation process.
  8. 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.
  9. If everything is fine the release manager tags the code in git and releases a tarball.
  10. The release is announced on the mailing list and in the blog.
  11. The freeze is lifted.

based on proposal at the LXDE developer mailing list.

Dependencies

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 following components are known to impact others:

  • menu-cache: libfm, lxpanel, lxlauncher
  • libfm: pcmanfm
  • lxsession: lxappearance, lxinput
  • lxsession: lxsession-edit
  • lxmenu-data: lxlauncher, lxpanel
  • pcmanfm: lxde-common (configuration only)
  • lxpanel: lxde-common (configuration only)
  • openbox: lxde-common (configuration only)

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. A translation related mailing list used for discussions about context and actual phrasing of the translatable content
  3. Please join us also in the LXDE contributors channel at irc.oftc.net #lxde

Links