(Difference between revisions)
|
|
| Line 16: |
Line 16: |
| | * 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: feature or bug # ==== | + | ==== Step 3: Changelog must refer to a feature or bug # ==== |
| | + | |
| | + | * My package's .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. |
| | + | * 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. |
| | | | |
| | ==== Step 4: Submit from correct place to correct place ==== | | ==== Step 4: Submit from correct place to correct place ==== |
Revision as of 03:59, 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.
- 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's .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.
- 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.
Step 4: Submit from correct place to correct place
- If my package is maintained under a devel: project, I must first submit my request to the devel: project.
- If my package is not maintained under a devel: project, I will branch
- All submissions will first be submitted to :Testing, and then be promoted by Release Engineering to Trunk.
Step 5: meego-release@
Additional Resources
This is a summary of the following detailed resources: