Development Team/Release

New features proposal

At the beginning of each release cycle, maintainers will write a proposal for each major new feature they plan to develop. These will be discussed on the Sugar mailing list, revises on the base of the feedback and made available on the wiki. New modules will require explicit approval by the release team.

As part of this new activities will be proposed for inclusion. Criteria for approval will be:

The maintainer is willing to follow the Sugar schedule.
Supports internationalisation and localisation.
Does not duplicate the functionalities of other activities.
...

Module release

For both intermediates and final releases module maintainers are responsible to announce module release and make the sources available. More in detail:

Build a source tarball, test it carefully and make it available in a stable location.
Send an announce mail to announce@sugarlabs.org. The form will be decided by each maintainer but it should at least include a reference to the source code tarball and an high level, user targeted list of changes.

Coordinated release

Each release cycle will include development, beta, release candidate and final releases. The release team is responsible to coordinate with module maintainers, pull the updated modules together, perform basic QA and announce it. More in detail:

Ensure that all the module releases are available by the scheduled date.
Construct a sugar-jhbuild moduleset out of them. Run automatic and manual QA on it.
If issues arise coordinate with the relevant module maintainers to solve them.
Announce the release on announce@sugarlabs.org, including a reference to the sugar-jhbuild moduleset, references to each source module and a global list of changes.

Feature freeze

The feature freeze affects all the modules included in the release and comprise also strings and ABI for public libraries. Exceptions might be considered by the release team but they will be extremely rare.

Hard code freeze

When the hard code freeze is in effect, each and every code change should be approved by the release team. Only critical fixes will be considered.

Automation

TBD Many of the steps described in this document can be easily automated or maintainers which are using the sugarlabs infrastructure. As a first pass we want to get the workflow right though, even if it involves more manual step than strictly required.