Difference between revisions of "Requesting an Update"
(→Main/Non-free/Restricted Packages) |
(→Main/Non-free/Restricted Packages) |
||
| Line 20: | Line 20: | ||
# Build and test your package '''first'''. Before asking ROSA teams to verify your package, you '''MUST''' test it yourself. Build it on ABF, install your own package, and check that it indeed fixes the issue by some simple test cases. If you're fixing a base system package, make sure your system boots and connects to network after your fix. | # Build and test your package '''first'''. Before asking ROSA teams to verify your package, you '''MUST''' test it yourself. Build it on ABF, install your own package, and check that it indeed fixes the issue by some simple test cases. If you're fixing a base system package, make sure your system boots and connects to network after your fix. | ||
| − | #; You must build your package using ABF into the correct repository ''under all supported architectures''! The links to ''build_list''s will be used by other teams to verify your new package.'''Please note that your internal test packages may be built into your private repository, but for publishing it must be built into the official repository.''' | + | #; You must build your package using ABF into the correct repository ''under all supported architectures''! The links to ''build_list''s will be used by other teams to verify your new package. '''Please note that your internal test packages may be built into your private repository, but for publishing it must be built into the official repository.''' |
# Make sure your package complies to [[Submission Policy]], i.e. contains the proper branches, and specs. | # Make sure your package complies to [[Submission Policy]], i.e. contains the proper branches, and specs. | ||
# Prepare an ''advisory text''. "Advisory" is what users see in their system update program near the package itself. The text should describe what ''exactly'' this update is for. | # Prepare an ''advisory text''. "Advisory" is what users see in their system update program near the package itself. The text should describe what ''exactly'' this update is for. | ||
Revision as of 13:52, 21 May 2012
This page details what steps should you take to deliver a fix to the package you maintain to PCs of all ROSA users worldwide. Given that this may put all users on risk, the ROSA updates should be tested prior to being rolled to mirrors.
Contents
Aims of the update process
The update process aims to verify that your update
- doesn't make the system crash, get unable to boot, install, or degrade its usability;
- doesn't expose system to known security risks;
- doesn't violate the integrity of repositories.
These three steps are covered by QA team, Security Team, and Repo-managers correspondingly.
For contributed packages included in the "contrib" repository", only the integrity is verified as well as that no packages in the main repository are damaged by the updated package.
What should a maintainer do
Main/Non-free/Restricted Packages
If you feel that you fixed a bug or a security issue in the package you maintain, and want to submit it to updates, do the following.
- Build and test your package first. Before asking ROSA teams to verify your package, you MUST test it yourself. Build it on ABF, install your own package, and check that it indeed fixes the issue by some simple test cases. If you're fixing a base system package, make sure your system boots and connects to network after your fix.
- You must build your package using ABF into the correct repository under all supported architectures! The links to build_lists will be used by other teams to verify your new package. Please note that your internal test packages may be built into your private repository, but for publishing it must be built into the official repository.
- Make sure your package complies to Submission Policy, i.e. contains the proper branches, and specs.
- Prepare an advisory text. "Advisory" is what users see in their system update program near the package itself. The text should describe what exactly this update is for.
- If your update is not a response to user's bug, create a bug in ROSA Bugzilla.
- Mark the bug this update fixes as RESOLVED FIXED. You will see a "Request for Update" checkbox; it will be disabled. To unlock it, write the advisory text in the comment (prepending with the word "Advisory:"), and write there also a link to the ABF build_list of the build you think is a fixed package. Set this checkbox, and submit changes to the bug.
- Wait for response from ROSA QA, Security and Release teams if there are issues with your package. Collaborate with them to fix the issues raised. If necessary, repeat step 6 to set the checkbox again.
- If there are no issues, the bug will be closed as VERIFIED, and at this point you will know that the update is being deployed unless it has already been.
FAQ
- How to edit advisory text?
- Post a new comment with the fixed text. There is no way to edit a Bugzilla comment.
- I posted advisory/build_list links to a previous comment, why is the checkbox inactive, and how do I activate it?
- Checkbox is inactive because it checks if the current comment contains it. Post the links and the text again for greater clarity.
Contrib Packages
Though highly advisable, you do not have to follow Category:Packaging Policies in your packages in "contrib" repo. ROSA QA and Security teams will not generally assist you in verifying your updates. However, a Repository Manager will have to quickly check if your package doesn't violate the integrity of the "main" repository of supported packages.
You are advised to do all of the steps described in #Main Packages, but in fact you may just open a bug, and then add a comment with a link to build_list, and a text "advisory: empty" in the comment (steps 5 and 6).
