(→Iteration cycle schedule) |
(→Common Mistakes and FAQs) |
||
| (31 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
== Developer's Submission Checklist == | == Developer's Submission Checklist == | ||
| - | This a checklist for | + | 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. | ||
| - | + | === Step 1: Builds Successfully === | |
| + | |||
| + | * My package builds successfully against the MeeGo repositories. | ||
| + | * My package complies with the [[Packaging/Guidelines|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: | ||
* [[Release_Engineering/Process|Release engineering process and work flow]] | * [[Release_Engineering/Process|Release engineering process and work flow]] | ||
* [[Packaging/Guidelines|MeeGo packaging guidelines]] | * [[Packaging/Guidelines|MeeGo packaging guidelines]] | ||
| - | == | + | == 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. | ||
| - | + | [[Category:Release engineering]] | |
Contents |
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.
This is a summary of the following detailed resources:
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.