MIC2 Development Release Processes

Contents 1 MIC2 development and release process 1.1 Development Process 1.2 Development/Unstable Release Process 1.3 Stable Release Process 1.4 Mailing list and Bugzilla 1.4.1 Mailing list 1.4.2 Bugzilla

MIC2 development and release process

Development Process

A developer can create a gitorious account then clone MIC2 git tree from http://meego.gitorious.org/meego-developer-tools/image-creator After creating a clone in gitorious it is possible to create a merge request on gitorious, once the changes are ready for merging. NOTE: no email notification is sent to maintainers, so to ensure your request is noticed sent an e-mail to MIC2 maintainer as well. After MIC2 maintainer noticed the merge request the request will be reviewed and based on that accepted/declined with comments.

It is also possible to file a bug in http://bugs.meego.com/enter_bug.cgi?product=Development%20Tools and attach patches with note what this patch is for, MIC2 team will pick up and apply them into MIC2 git tree after reviewing. NOTE: use git to generate the patch if you want to preserve the log and author information in MIC2 git tree.

Development/Unstable Release Process

In order to find and fix MIC2 issues as early as possible, we need QA to test MIC2 development/unstable release every Wednesday, MIC2 maintainer will cut a release in MIC2 git tree and package it in devel:tools:building:unstable/mic2, then MIC2 team requests QA to start testing it, QA will send a formal test report after test is done, any bug found during test will be filed in http://bugs.meego.com/enter_bug.cgi?product=Development%20Tools, MIC2 developers will take critical/blocking bugs (release managers have right to decide them) and fix them as soon as possible in MIC2 git tree, MIC2 maintainer will cut a new development/unstable release in MIC2 git tree and package it in devel:tools:building:unstable/mic2 for next development release test cycle once all the critical/blocking bugs are fixed. If QA didn't find any critical/blocking issues, MIC2 maintainer can push this unstable release to stable project devel:tools:building/mic2 and trigger QA to test stable release, MIC2 maintainer also can continue to develop without releasing it as stable.

The below steps and flow chart give a clearer statement:

1. Cut a release in mic2 git tree (http://meego.gitorious.org/meego-developer-tools/image-creator)
2. Update mic2 in devel:tools:building:unstable
3. QA uses devel:tools:building:unstable to verify
4. QA sends out test report
5. Fix bugs QA found if any blocking issue and repeat step #1 - #5, else go to step #6
6. Submit devel:tools:building:unstable/mic2 to devel:tools:building if release as stable, else continue to develop or fix blocking issues QA found then repeat step #1 - #5

Stable Release Process

Once QA's test report indicates that a development/unstable release has good quality and stability for stable release, MIC2 maintainer will push devel:tools:building:unstable/mic2 to devel:tools:building/mic2 and trigger MIC2 stable release process. Some hot/critical fixes for last stable release can also trigger a stable release process, for example, release managers found a severe issue which blocked them to create a release image, MIC2 developers must take this right now and fix it as soon as possible, once fix patch is ready, MIC2 maintainer should update devel:tools:building/mic2 with this fix patch (MIC2 developer must ensure this fix patch is also put into MIC2 git tree) and request QA to start testing (this may be on demand). We will have a stable release every other Friday.

QA will send a formal test report for a stable release once test is done, any related bug will be filed in http://bugs.meego.com/enter_bug.cgi?product=Development%20Tools, MIC2 developers must take these bugs seriously, those critical/blocking bugs should be fixed as soon as possible, release managers have right to decide which bugs are critical/blocking.

If there isn't any critical/blocking issue and release managers agree this should be pushed to public, MIC2 maintainer will push devel:tools:building/mic2 to Tools:Building/mic2, tools repo administrator will sync this into repo.meego.com/MeeGo/tools, finally MIC2 team will send release notes to public.

The below steps and flow chart give a clearer statement:

1. Fix some hot/critical bugs (from http://bugs.meego.com/enter_bug.cgi?product=Development%20Tools&component=MIC%20(Image%20Creator) or release team) in mic2 git tree
2. Update mic2 in devel:tools:building with these fixes (just cherry pick these fixes)
3. QA uses devel:tools:building to verify
4. QA sends out test report
5. If release managers think we can release it, go to step #6, else repeat steps #1 to #4
6. Submit mic2 in devel:tools:building to Tools:Building
7. Accept it and sync it to http://repo.meego.com/MeeGo/tools/
8. Send release notes to meego-distribution-tools@lists.meego.com, meego-releases@meego.com and meego-dev@meego.com

Mailing list and Bugzilla

Mailing list

We have created a mailing list meego-distribution-tools@lists.meego.com on meego.com (please go to http://lists.meego.com/listinfo/meego-distribution-tools to subscribe it).

• all changes against mic2 git tree will be sent into this mailing list when committed, anyone can give some feedback if she/he has comments about the changes
• all the issues or discussion related to mic2 will be sent to this mailing list as well

Bugzilla

Bugzilla product for MIC2 related bugs is Development and component is MIC (Image Creator), http://bugs.meego.com/enter_bug.cgi?product=Development%20Tools&component=MIC%20(Image%20Creator)

When you found a mic2 issue, please help to file a bug and describe your issue as detailed as possible. You should include as much as possible from the following information:

• The full command line you used when the error occurred
• the whole log (stdout and stderr)
• kickstart file
• linux distribution used (Fedora 13, Debian 5.0, Ubuntu 10.10 or others)
• The host architecture where the build was done, e.g., x86 or x86_64
• Steps how the issue can be reproduced.