Changes

Development Team/Release (view source)

Revision as of 04:12, 10 May 2008

752 bytes added , 04:12, 10 May 2008

no edit summary

Line 1: Line 1:

== New features proposal ==

−

At the beginning of each release cycle, maintainers will write a proposal for each major new feature they plan to develop. ~~They~~ 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.

+

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:

Line 9: Line 9:

* 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.

== Feature freeze ==

Line 17: Line 24:

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.

Marcopg

607

edits