Release Engineering/Submission Checklist

Revision as of 20:40, 14 April 2011

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.
  • This holds good even if my change is trivial and cosmetic.
  • 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 source to correct destination project

• All submissions will first be submitted to a relevant Meego :Testing project, and then be promoted by Release Engineering to Trunk.
  • such as 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.
  • such as home:<username>:branches:devel:qt-mtf/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.
  • such as osc branch Trunk:Testing mlocate
  • This will create a home branch for you to work in - home:$user:branches:Trunk:Testing/mlocate

Step 5: If API/ABI changes

• Once a package update/upgrade involves a ABI changes, before submitting to T:T, please send an notification to meego-dev and meego-packaging and let release engineers know with detailed information of
  • what has changed
  • what are required to do in upper stack to work with the ABI changes
  • soname obviously must bump since ABI changes
• Same applies with API changes, especially for those very basic packages many packages use as Build dependencies, please let public know. To get know which packages are rely on your package, you could use localcheckbuild tool, and osc native command of whatdependson

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 submissions, a valid bug # or feature # is required. If it does not exist, 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.