Difference between revisions of "Requesting an Update"
From Rosalab Wiki
(→Exceptions) |
Pavel.shved (Talk | contribs) (→Main/Non-free/Restricted Packages: explanation, supposed to fix bug 570.) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 26: | Line 26: | ||
# 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. | ||
# If your update is not a response to user's bug, create a bug in [[Using ROSA Bugzilla|ROSA Bugzilla]]. | # If your update is not a response to user's bug, create a bug in [[Using ROSA Bugzilla|ROSA Bugzilla]]. | ||
| − | # Mark the bug this update fixes as RESOLVED FIXED. You will see a [http://coldattic.info/pic/13643245922220423217.png "Request for Update" checkbox]; it will be disabled. | + | # Mark the bug this update fixes as RESOLVED FIXED but '''do not save changes yet'''. You will see a [http://coldattic.info/pic/13643245922220423217.png "Request for Update" checkbox]; it will be disabled. Your comment must contain: |
| + | ## advisory text (prepended with the word "Advisory:"); | ||
| + | ## links to the ABF build_list-s (under all architectures) you prepared at the step 2; | ||
| + | ## a note that the package requires "extended testing" if you think it needs one. | ||
| + | #:The first two points will unlock the checkbox; mark it, and submit changes to the bug. | ||
| + | # If your update is not a response to user's bug, create a bug in [[Using ROSA Bugzilla|ROSA Bugzilla]]. | ||
# 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. | # 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. | # 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. | ||
| Line 43: | Line 48: | ||
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). | 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). | ||
=== Exceptions === | === Exceptions === | ||
| − | # While we will change this in future, currently there is one exception. KDE packages should be built into your clean private repo and while requesting an update you should provide link to you private repository with the whole KDE stack. Afterwards, if the update is approved, all packages will be rebuilt | + | # While we will change this in future, currently there is one exception. KDE packages should be built into your clean private repo and while requesting an update you should provide link to you private repository with the whole KDE stack. Afterwards, if the update is approved, all packages will be rebuilt by repository admins and published to the main repository. |
Latest revision as of 09:13, 24 July 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.
- Make a proper build
Now you should build your package and publish the links to the build_list-s, which will be used to verify your package.- You must build your package under all supported architectures (these are i586 and x86_64)!
- Please note that your internal test packages may be built into your private repository, but, at this point, prior to publishing, it must be built into the official repository! (I.e. into "rosa2012lts").
- 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 but do not save changes yet. You will see a "Request for Update" checkbox; it will be disabled. Your comment must contain:
- advisory text (prepended with the word "Advisory:");
- links to the ABF build_list-s (under all architectures) you prepared at the step 2;
- a note that the package requires "extended testing" if you think it needs one.
- The first two points will unlock the checkbox; mark it, and submit changes to the bug.
- If your update is not a response to user's bug, create a bug in ROSA Bugzilla.
- 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).
Exceptions
- While we will change this in future, currently there is one exception. KDE packages should be built into your clean private repo and while requesting an update you should provide link to you private repository with the whole KDE stack. Afterwards, if the update is approved, all packages will be rebuilt by repository admins and published to the main repository.
