Release Engineering/Submission Checklist

Revision as of 04:46, 23 November 2010

Developer's Submission Checklist

This a checklist for developer's submitting their code to MeeGo via OBS http://build.meego.com

Following this checklist will ensure smooth submission and acceptance of code.

Step 1: Builds Successfully

• My package builds successfully against the MeeGo repositories.
• My package complies with the packaging guidelines.
• My package does not break other packages. If there is an API change or other changes that might break dependent packages, I will notify Release Engineering by emailing the meego-packaging@meego.com mailing list.

Step 2: Test

• I have tested my changes on all relevant hardware. All code must be solid and tested before submission.
• If I make a change to a big package with a lot of dependents like the kernel, qt, etc. I will make sure this does not break any MeeGo verticals.
• If my change will cause regressions, I must communicate with Release Engineering on what the expected regressions will be, and the ETA of when this can be rectified.

Step 3: Changelog must refer to a feature # or bug #

• My package .changes file and commit message refer to a valid bug # or feature # in bugzilla.
  • If my change is trivial and cosmetic, then I can by-pass this step.
  • For major package upgrades that include new features or major API changes, a feature # is required. For minor package upgrades to a package that mostly includes bug fixes, a bug # will suffice.
• If there isn't an existing bug #, then I will file one and refer to it.
• If there isn't an existing feature #, then I will file one and wait for the product management forum to set the feature state to ACCEPTED, then submit my change.
• Once I submit my change, I will change the status of the bug # or feature # to RESOLVED.
• The status will be changed to RELEASED by Release Engineering once the submission has made it into Trunk.

Step 4: Submit from correct place to correct place

• All submissions will first be submitted to a relevant Meego :Testing project, and then be promoted by Release Engineering to Trunk.
  • e.g. developer submits to Trunk:Testing project. Then Release Engineering will promote that change to Trunk if all goes well.
• If my package is maintained under a devel: project, I must first submit my request to the corresponding devel: project. The devel: maintainer will then be responsible for submitting from the devel: project to the appropriate MeeGo :Testing project.
  • e.g. qt -> devel:qt-mtf -> Trunk:Testing -> Trunk
• If my package is not maintained under a devel: project, I will branch using the 'osc branch $project $pkg' command, where $project refers to the target $project I am submitting to.
  • e.g. osc branch Trunk:Testing mlocate
  • This will create a home branch for you to work in - home:$user:branches:Trunk:Testing/mlocate

Additional Resources

This is a summary of the following detailed resources:

• Release engineering process and work flow
• MeeGo packaging guidelines

Common Mistakes and FAQs

No bug # or feature # in the changelog or commit message

Don't forget, for all non-trivial submissions, a valid bug # or feature # is required. If non exists, you need to file one.

Do not Submit from a home:$user project

Submissions must either come from a devel: project or an official branch of the package (using 'osc branch', which automatically create home:$user:branches:$project:$pkg that builds against the appropriate repositories). It should not come straight from your home:$user project which you linked manually.

The submission was not tested

A lot of times packages are accepted and then revoked because proper unit-testing was not done, and it caused an unexpected regression.