Latest revision as of 13:18, 17 June 2011

Processes to handle MeeGo Bugzilla Requests

DRAFT STATUS - see mailing list thread

This process is to ensure new features or changes to MeeGo Bugzilla itself are implemented & deployed under the planned way and also to ensure the MeeGo Bugzilla features & changes are generic enough for most users.

How MeeGo Bugzilla requests are handled

• Have a bug report or feature request for the complete requests both for code level and new custom fields & new flags;
• Error management team will provide feedback in one working day normally once receive the request notification;
• The follow up and feedbacks should happen in the bug/feature comments in the report;
• For minor change like component adjustment and component owner changes, MeeGo Bugzilla admins will go ahead directly but nice to have a ticket.

Process to accept & review & integrate code level changes

• There will be a personal repository branch for each one has the source code submission privilege in MeeGo Bugzilla git repository;
• Submit the new feature & bug fix into personal repository branch;
• Merge the changes into staging branch after code cross review;
• Deploy the changes into staging Bugzilla;
• Feedbacks from testing on our staging instances (1, 2);
• Merge the changes from staging branch to production branch once code quality is good enough;
• Deploy the changes into production Bugzilla;