[sugar] Release schedule and process

[Marco Pesenti Gritti]

Hello,

I wrote some notes about the process for the next Sugar release.

http://wiki.sugarlabs.org/go/Release
http://wiki.sugarlabs.org/go/Roadmap

Posting them inline here for discussion.

Feedback very welcome!

Thanks,
Marco

---

== Schedule ==

May 1 	Development start - New features proposal
May 14 	Sugar 0.81.1 Tarballs Due 	
May 15 	Sugar 0.81.1 Development Release 	
May 31 	Sugar 0.81.2 Tarballs Due 	
June 1 	Sugar 0.81.2 Development Release 	
June 14 	Sugar 0.81.3 Tarballs Due 	
June 15 	Sugar 0.82 Beta 1 (0.81.3) - Feature, ABI, String freeze
June 30 	Sugar 0.81.4 Tarballs Due 	
July 1 	Sugar 0.82 Beta 2 (0.81.4) 	
July 14 	Sugar 0.81.5 Tarballs Due 	
July 15 	Sugar 0.82 Release Candidate 1 (0.81.5) 	
July 22 	Sugar 0.81.6 Tarballs Due 	
July 23 	Sugar 0.82 Release Candidate 2 (0.81.6) - Hard Code Freeze
July 31 	Sugar 0.82 Tarballs Due 	
August 1 	Sugar 0.82 Final Release

== Moduleset ==

* sugar
* sugar-base
* sugar-datastore
* sugar-presence-service
* sugar-toolkit
* sugar-artwork
* journal-activity

== Dependencies ==

* hippo-canvas
* telepathy-glib
* telepathy-gabble
* telepathy-salut
* telepathy-python

---

== 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, revised 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 process 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.
* ...

Not required but preferred:

* Use the sugarlabs infrastructure.

== 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 devel-announce at 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 oriented
list of changes.

== Sugar 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 devel-announce at 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. To
request an exception send mail to release-team at sugarlabs.org.

== 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. To request approval send mail to
release-team at sugarlabs.org, including the patch and a detailed
description of the changes, the benefits and the risks. Approval will
have to be granted by at least two [[ReleaseTeam#People|members]] of
the team.

== Roadmap ==

The [[Roadmap]] is updated at the beginning of each release cycle by
the release team. It includes:

* Detailed schedule of release dates and freeze points.
* List of modules and external dependencies.
* Reference to all the tickets considered for the release.
* References to the new feature proposals.

== Bug triaging ==

Module maintainers should ensure that their plans for the release are
clearly reflected in the bug tracking system. They are responsible to
set milestones and priorities accordingly, in cooperation with the
release and the QA teams.

Without making it a strict rule, it would be good if each commit or
set of commit would have a ticket associated. The ticket number should
be always mentioned in the git log and could also be used to
automatically build the list of module changes for the releases.

== Automation ==

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