View source for Requesting an Update

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.

=== 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''' <br/>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 [[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.  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. [[Using ROSA Bugzilla#How to edit a comment|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.