Meego Wiki
Views

Release Engineering/Submission Checklist

From MeeGo wiki
(Difference between revisions)
Jump to: navigation, search
(→Common Mistakes and FAQs)
(categorise, wikify section headings)
Line 5: Line 5:
Following this checklist will ensure smooth submission and acceptance of code.
Following this checklist will ensure smooth submission and acceptance of code.
-
==== Step 1: Builds Successfully ====
+
=== Step 1: Builds Successfully ===
* My package builds successfully against the MeeGo repositories.
* My package builds successfully against the MeeGo repositories.
Line 11: Line 11:
* 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.
* 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 ====
+
=== Step 2: Test ===
* I have tested my changes on all relevant hardware.  All code must be solid and tested before submission.
* I have tested my changes on all relevant hardware.  All code must be solid and tested before submission.
Line 17: Line 17:
* 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.
* 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 # ====
+
=== 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.
* My package .changes file and commit message refer to a valid bug # or feature # in bugzilla.
Line 27: Line 27:
* The status will be changed to RELEASED by Release Engineering once the submission has made it into Trunk.
* 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 ====
+
=== 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.
* All submissions will first be submitted to a relevant Meego :Testing project, and then be promoted by Release Engineering to Trunk.
Line 37: Line 37:
** This will create a home branch for you to work in - home:$user:branches: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 ====
+
=== 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
*  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
Line 65: Line 65:
A lot of times packages are accepted and then revoked because proper unit-testing was not done, and it caused an unexpected regression.
A lot of times packages are accepted and then revoked because proper unit-testing was not done, and it caused an unexpected regression.
 +
 +
[[Category:Release engineering]]

Revision as of 12:07, 12 April 2011

Contents

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 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. 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.
    • e.g. 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:

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.

Retrieved from "http://wiki.meego.com/Release_Engineering/Submission_Checklist"
Personal tools