openSUSE:Howto Submit from Tumbleweed to SLES
How to submit a package from Tumbleweed to SLE
As we aim to have all the changes from SLE also in Tumbleweed (see: Factory First Policy), it quickly brings up the question.
"Can I not just submit my Tumbleweed package to SLE and be done with it?"
In general the answer is: Yes you can.
But of course there is a but.
Goals
- Do not lose any relevant information about past changes. Especially bug and CVE references.
- Do not introduce regressions
History
In the past the submission would have required that you copy in the source changes and then write a summary changes entry in the original SLE changes file. This option ensured that we did have a consistent changes file.
One important point that should be made clear here: When a package gets rejected for "lost changes entries/bugnumbers" ... the real question is not about the changes file. It is about "did we also lose the fixes associated with those lost entries. If the package the followed factory first policy, the chances are low, but not zero. Possible reasons:
- We might backport a fix to a SLE version from upstream, but then of course we do not add the bugnumber to the changes file in Tumbleweed
- Factory first policy is not enforced for maintenance submissions in general
While this historical way worked, and is similar to what you would do when merging between different stable branches in git, many packagers were unhappy with the extra work. If you want to follow this procedure you still can submit from Tumbleweed without having to modify the changes file.
Making it easier
Since a few service packs now we allow for an easy policy:
- Verify that all the fixes from the SLE package are also in Tumbleweed. For this you can use e.g.:
iosc rdiff SUSE:SLE-15-SP5:Update/yourpackage openSUSE.org:openSUSE:Factory/yourpackage
While doing this step collect all the dropped bug references and patch names. - Submit your package.
iosc sr openSUSE.org:openSUSE:Factory/yourpackage SUSE:SLE-15-SP6:GA
Now discard the default submitrequest message and instead add the following informations
- Jira ID for the version update. Important note here: Use the Jira ID for the implementation issue not the epic. If you have to update the Jira IDs from Epic to implementation issue, please also explain that in the message.
- List of all lost bug references and a clarification that you verified that all those fixes are still present in the Tumbleweed package, so we do not want to introduce regressions. Of course if you can match bugnumbers/CVEs to version updates in Tumbleweed than please add those bugnumbers there and check in a changes file only commit.
- List of all dropped patches to follow the patch policy
If you follow those steps your package should be accepted just fine. This also shows if you follow the factory first policy properly and make sure that all your SLE changes are also in Tumbleweed, than this step will become a lot easier.