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]]