Home

Policies

Posted March 26th, 2006 by koen
in

Rules

  • If it isn't in the SCM, download areas or bugtracker, it doesn't exist
  • IRC is nice, but big decisions go over the mailinglist(s)
  • OE != Angstrom
  • The release team has the final say in release matters

Open issues

  • Who defines the goals?
  • how much power has a mentor?
  • how is the release team composed?

Release Policy

When the release goals have been decided and most of the package versions have been fixated a new branch will be created. Right after branching the release team will do a build for all machines in the release set and populate the feeds. The feed URIs in the branch will be changed to point to the newly created feeds. The DISTRO_VERSION will now contain the release version and a tag to denote the alpha status. The buildmaster(s) will invoke the magic switch to build images from the feeds instead of deploy/ipk.

The release team makes sure that 'alpha1' gets tested by the machine mentors. Every image should boot and have start the 'environment' (gpe/opie/e/etc) and 'ipkg update; ipkg upgrade' using the preconfigured feeds will give no errors. Bugs found during that session will go into the bugtrackers, get fixed in .dev and copied to the branch in such a way that it can be easily tracked and updated packages will go into the feeds.

People will start building World, an SDK and the native packages and put those in the feeds as well.

When those bugs have been fixed DISTRO_VERSION will get bumped to RC status and image will be made available for users. Once all the machine mentors state that all blockers have been fixed a final RC will be built and tested for a short period (±2 weeks). When that's been successfull the release team will give a 'go' and the branch will be tagged, images be built and uploaded and our PR squad will announce it to the world.

The changelog will contain some blurb about improvements, new features and fixed bugs like GTK does.

RFC: gpg signing of releases and packages

Back to top