Meego Wiki
Views

Release Engineering/Submission Checklist

From MeeGo wiki
(Difference between revisions)
Jump to: navigation, search
(I am submitting to :Testing)
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.
-
=== I am submitting to :Testing ===
+
=== Submitting code to MeeGo ===
-
something
+
==== 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.
 +
* 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 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@ ====
=== From :Testing to Trunk ===
=== From :Testing to Trunk ===

Revision as of 03:34, 23 November 2010

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.

Submitting code to MeeGo

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: feature or bug #

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@

From :Testing to Trunk

something


Additional Resources

This is a summary of the following detailed resources:

Personal tools