Quality/MeeGoBugzillaRequestProcess

Revision as of 05:25, 17 June 2011

Processes to handle the MeeGo Bugzilla Requests

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

• Here is the brief process summary of how MeeGo Bugzilla request is handled:
  • Have a bug entry or feature entry for all change requests both for code level and new custom fields & new flags;
  • Error management team will provide feedbacks in one working day normally once receive the request notification;
  • The follow up and feedbacks could be happened at bug/feature comments;
  • Use Severity field to identify how urgent & important the request is;
  • The bug or feature assignee will use priority field to identify how urgent and important the request is;
  • Use target milestone to indentify when the change could be ready especially for large changes need the code level customization;
  • For minor change like component adjustment and component owner changes, MeeGo Bugzilla admins will go ahead directly but nice to have a bug entry for change request;

• To ensure the quality of changes bring to MeeGo bugzilla, here is the 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;
  • Merge the changes from staging branch to production branch once code quality is good enough;
  • Deploy the changes into production Bugzilla;

• You have a change request? File a ticket [[1]]

• You have a feature request? File a ticket [[2]]