Update.1 process: Difference between revisions
Jump to navigation
Jump to search
m (Update.1 process moved to Ship.2 process: Update.1 has been slipped in favor of Ship.2.) |
m (Unprotected "Update.1 process") |
||
| (8 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
{{OLPC}} |
|||
==Process to Propose Changes== |
|||
# You MUST notify the community of any significant code you expect will change as soon as possible. |
|||
# To do this, you MUST create a ticket, tagged "Update.1?" in the keywords field. You MUST briefly justify your recommendation. You MUST include the date you expect your change will [[Build system|be available]] for testing in the "joyride" build. |
|||
# You SHOULD tag other people's bugs that you think should be included in Update.1. But remember that there is a finite amount of time and resources available as you make these recommendations, and state your reasoning why you think these fixes must be made by our first deployment release. |
|||
# After November 1, the exact RPM or bundle version will be indicated in the ticket requesting the change in Update.1, with its checksum and diffs from the previous version, and proposed CHANGELOG entry. It must be is available in a Joyride build for testing and ready for inclusion in Update.1. We strongly encourage that you have someone other than yourself verify that your fix is correct and does not introduce regressions. |
|||
==Process to Approve Changes to Update.1== |
==Process to Approve Changes to Update.1== |
||
The release team will approve tickets and assign to the designated release engineer ( |
The release team will approve tickets and assign to the designated release engineer (for Update.1, this is dgilmore). |
||
To suggest a bug to be fixed in the release, please set the milestone to "Retriage Please!" and make the case, preferably with a patch (previously, this was signaled by keywords "update.1?", "Update.1?", "Update1?" and so on, causing errors in handling requests). JG will periodically scan this list and decide what should go in for the release. Feel free to ping him to get fast action if need be. |
|||
* Once approved, you can upload the packages for Joyride. |
|||
* The bundles/RPMS MUST be present in Joyride for anything not coming from Koji (the Fedora build system). Note that SRPM's for each RPM MUST also be present, and should be updated each time the binary RPM is updated. Activity bundles that are solely Python do not need separate SRPM's; if your activity contains binary code, we expect the source/SRPM's to also be present along with the activity bundle; please discuss with us how to package your sources. |
* The bundles/RPMS MUST be present in Joyride for anything not coming from Koji (the Fedora build system). Note that SRPM's for each RPM MUST also be present, and should be updated each time the binary RPM is updated. Activity bundles that are solely Python do not need separate SRPM's; if your activity contains binary code, we expect the source/SRPM's to also be present along with the activity bundle; please discuss with us how to package your sources. |
||
To get approval for bug fixes or some remaining enhancement to actually go into Update.1, use the following process: |
To get approval for bug fixes or some remaining enhancement to actually go into Update.1 once tested in Joyride, use the following process: |
||
* there MUST be at least one ticket in Trac, it should already have been marked for resolution in Update.1; it can reference additional tickets to be closed by the commit, and should clearly indicate exactly which bundle or RPM should be applied to Update.1. |
* there MUST be at least one ticket in Trac, it should already have been marked for resolution in Update.1; it can reference additional tickets to be closed by the commit, and should clearly indicate exactly which bundle or RPM should be applied to Update.1. |
||
| Line 19: | Line 18: | ||
* The ticket should contain the patches being applied so that we can review them. If possible, please tell us how to verify the bug fix. |
* The ticket should contain the patches being applied so that we can review them. If possible, please tell us how to verify the bug fix. |
||
* You MUST indicate who is going to verify the fix is in Update.1, so it is obvious |
* You MUST indicate who is going to verify the fix is in Update.1, so it is obvious to whom the build engineer should reassign the bug. |
||
* Assign the trac bug to the user "ApprovalForUpdate". Add yourself to the list to ensure you get notification of any changes. This will let Jim/Kim/Walter have a single work queue; if you can catch us on IRC, you may be able to get approval immediately. |
* Assign the trac bug to the user "ApprovalForUpdate". Add yourself to the list to ensure you get notification of any changes. Marco can approve submissions for items involving Sugar, Journal, and the Browser. This will let Jim/Kim/Walter/Marco have a single work queue; if you can catch us on IRC, you may be able to get approval immediately. |
||
* When approved, the ticket will be assigned to the release master. |
|||
* Dennis will assign it back to the designated tester once the next Update.1 build is complete. |
|||
* If it is approved, we'll assign the trac entry to our buildmeister |
* If it is approved, we'll assign the trac entry to our buildmeister to process. |
||
* When the update is in the new Update.1 build, the buildmeister will reassign it back to you. |
* When the update is in the new Update.1 build, the buildmeister will reassign it back to you. |
||
* You are then expected to test the resulting Update.1 build, and mark the bug(s) closed and verified. |
* You are then expected to test the resulting Update.1 build, and mark all the bug(s) fixed by the Update.1 build closed and verified. |
||
We hope/expect further enhancements in the trac system (new workflow facilities in the new version of Trac we've begun using) will help improve and simplify the process for the next release. But as it is after feature freeze, we'll live with this process this release rather than debug a new/better one. |
|||
Latest revision as of 23:57, 3 August 2008
This page is monitored by the OLPC team.
Process to Approve Changes to Update.1
The release team will approve tickets and assign to the designated release engineer (for Update.1, this is dgilmore).
To suggest a bug to be fixed in the release, please set the milestone to "Retriage Please!" and make the case, preferably with a patch (previously, this was signaled by keywords "update.1?", "Update.1?", "Update1?" and so on, causing errors in handling requests). JG will periodically scan this list and decide what should go in for the release. Feel free to ping him to get fast action if need be.
- Once approved, you can upload the packages for Joyride.
- The bundles/RPMS MUST be present in Joyride for anything not coming from Koji (the Fedora build system). Note that SRPM's for each RPM MUST also be present, and should be updated each time the binary RPM is updated. Activity bundles that are solely Python do not need separate SRPM's; if your activity contains binary code, we expect the source/SRPM's to also be present along with the activity bundle; please discuss with us how to package your sources.
To get approval for bug fixes or some remaining enhancement to actually go into Update.1 once tested in Joyride, use the following process:
- there MUST be at least one ticket in Trac, it should already have been marked for resolution in Update.1; it can reference additional tickets to be closed by the commit, and should clearly indicate exactly which bundle or RPM should be applied to Update.1.
- If there are any inter-dependencies on other fixes, this MUST be made clear clear.
- The ticket should contain the patches being applied so that we can review them. If possible, please tell us how to verify the bug fix.
- You MUST indicate who is going to verify the fix is in Update.1, so it is obvious to whom the build engineer should reassign the bug.
- Assign the trac bug to the user "ApprovalForUpdate". Add yourself to the list to ensure you get notification of any changes. Marco can approve submissions for items involving Sugar, Journal, and the Browser. This will let Jim/Kim/Walter/Marco have a single work queue; if you can catch us on IRC, you may be able to get approval immediately.
- When approved, the ticket will be assigned to the release master.
- Dennis will assign it back to the designated tester once the next Update.1 build is complete.
- If it is approved, we'll assign the trac entry to our buildmeister to process.
- When the update is in the new Update.1 build, the buildmeister will reassign it back to you.
- You are then expected to test the resulting Update.1 build, and mark all the bug(s) fixed by the Update.1 build closed and verified.
We hope/expect further enhancements in the trac system (new workflow facilities in the new version of Trac we've begun using) will help improve and simplify the process for the next release. But as it is after feature freeze, we'll live with this process this release rather than debug a new/better one.