Meego Wiki
Views

Release Engineering/Submission Checklist

From MeeGo wiki
< Release Engineering(Difference between revisions)
Jump to: navigation, search
(→Common Mistakes and FAQs)
(→Common Mistakes and FAQs)
 
(3 intermediate revisions not shown)
Line 1: Line 1:
== Developer's Submission Checklist ==
== Developer's Submission Checklist ==
-
This a checklist for developer's submitting their code to MeeGo via OBS http://build.meego.com
+
This a checklist for developers submitting their code to MeeGo via OBS http://build.meego.com
Following this checklist will ensure smooth submission and acceptance of code.
Following this checklist will ensure smooth submission and acceptance of code.
Line 25: Line 25:
* 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.
* 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.
* 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.
+
* 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 ===
=== Step 4: Submit from correct source to correct destination project ===
Line 39: Line 39:
=== 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
+
*  If a package update/upgrade involves ABI changes, before submitting to T:T, please send a notification to meego-dev and meego-packaging and let release engineers know, including detailed information about:
** what has changed
** what has changed
-
** what are required to do in upper stack to work with the ABI changes
+
** what must be done in upper stack to work with the ABI changes
** soname obviously must bump since 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
+
* Same applies with API changes, especially for those very basic packages that many packages use as Build dependencies. Please let the public know. To see which packages rely on your package, you could use localcheckbuild tool, and osc native command of whatdependson
=== Additional Resources ===
=== Additional Resources ===
Line 61: Line 61:
'''Do not Submit from a home:$user project'''   
'''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.
+
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'''
'''The submission was not tested'''

Latest revision as of 14:27, 15 April 2011

Contents

Developer's Submission Checklist

This a checklist for developers 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 your package upgrade doesn't touch code, and is merely a cosmetic (configuration) change, no Bug number is required.
    • 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

  • If a package update/upgrade involves ABI changes, before submitting to T:T, please send a notification to meego-dev and meego-packaging and let release engineers know, including detailed information about:
    • what has changed
    • what must be done 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 that many packages use as Build dependencies. Please let the public know. To see which packages 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

If your package upgrade doesn't touch code, and is merely a cosmetic (configuration) change, no Bug number is required. Don't forget, for code changes, 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