Meego Wiki
Views

Release Engineering/New Package Checklist

From MeeGo wiki
(Difference between revisions)
Jump to: navigation, search
(New package checklist)
(New package checklist)
Line 1: Line 1:
== New package checklist ==
== New package checklist ==
-
This a checklist for developer's submitting their code to MeeGo if this is a NEW package for http://build.meego.com. This checklist talks about only specical parts for new package, for other commen practise required to submit code to MeeGo, please follow [[Release_Engineering/Submission_Checklist|Submission Checklist]]
+
This a checklist which developers have to follow to submit a new package to MeeGo OBS of http://build.meego.com. This checklist talks about only specical parts for new package, for other commen practise required to submit code to MeeGo, please follow [[Release_Engineering/Submission_Checklist|Submission Checklist]]
Following this checklist will ensure smooth submission and acceptance of NEW package.  
Following this checklist will ensure smooth submission and acceptance of NEW package.  

Revision as of 15:16, 25 January 2011

Contents

New package checklist

This a checklist which developers have to follow to submit a new package to MeeGo OBS of http://build.meego.com. This checklist talks about only specical parts for new package, for other commen practise required to submit code to MeeGo, please follow Submission Checklist

Following this checklist will ensure smooth submission and acceptance of NEW package.

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 #

Personal tools