Development Team/Release

Team Home   ·   Join   ·   Contacts   ·   Resources   ·   FAQ   ·   Roadmap   ·   To Do   ·   Meetings

New features proposal

At the beginning of each release cycle, maintainers will write a proposal for each major new feature they plan to develop. The release team's role is to help the community to reach a consensus on which features, modules and activities to include.

New activities

To propose a new activity send mail to the sugar mailing list, providing the following informations:

• Short description of the features.
• Screenshots or screencasts.
• Are you willing to follow the Schedule?
• System components the activity depends on.
• Maintainer and members of the developer team, wth links to a User page on the wiki or their homepage on the web.
• Status of internationalization.
• Code repository.
• Bug tracking system.
• Homepage.

Criteria for approval will be:

• Supports internationalisation and localisation.
• Does not duplicate the functionalities of other activities.
• Provide functionality that the community judges as important for reaching the goals of the project.
• ...

Not required but preferred:

• Use the Sugar Labs infrastructure.

Module release

For both intermediates and final releases module maintainers are responsible to announce the module release and make the sources available. Note that the release number of the module does not need to match the Sucrose release number. More in detail:

• Build a source tarball, test it carefully and make it available in a stable location. The preferred location is http://dev.laptop.org/pub/sugar/sources/ which translates to: dev.laptop.org:/var/www/sugar/sources/ You need a developer account to be able to upload there.
• In git add a tag to reference the release. The tag name should be in the vXXX form (for example v20 for an activity, v0.81.9 for a Glucose module).
• Send an announce mail to sugar@laptop.org, with [RELEASE] in the subject. 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.

Activity sources

If your activity uses bundlebuilder you can use the dist_source command to generate a source tarball. Note, use a clean checkout of the repository - due to how bundlebuilder works at the moment files you would place in the directory e.g. x.patch would be included in the tarball as well.

 python setup.py dist_source

The tarball will be generated inside the dist directory.

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 sugar@laptop.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 sugar@laptop.org, referencing the patches you would like to land. It will have to be granted by two members of the release team, on the base of community feedback. For string changes please also copy localization@lists.laptop.org. As soon as the change is committed in git, notify the localization list about it.

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 sugar@laptop.org, including the patch and a detailed description of the changes, the benefits and the risks. Approval will have to be granted by two members of the team.

Branching

At the beginning of each unstable development cycle, a branch is usually created to host development on the stable release. It should be done lazily, whenever unstable changes are ready to be committed on master. Please use name in the sucrose-XXX form (for example sucrose-0.82). Each module maintainer is responsible to inform the sugar@laptop.org and localization@laptop.org lists about the branch.

You can create a remote branch like this:

git clone git+ssh://dev.laptop.org/git/sugar
cd sugar
git branch sucrose-0.82
git push origin sucrose-0.82

And to work on it:

git clone git+ssh://dev.laptop.org/git/sugar
git checkout --track -b sucrose-0.82 origin/sucrose-0.82
git pull

Roadmap

The ReleaseTeam/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.

Each commit or set of commit should have a ticket associated. The ticket number should be always mentioned in the git log and is 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 Sugar Labs 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.