Hi @ll You might have noticed, that SUSE started with the next service pack (SP4) for SLE-15 already. As there is a general guideline for all packagers to submit their packages to "Factory first", we noticed that there might be some conflicts with packages, that will differ between SLE and Factory. The following is especially interesting for SUSE packagers (but reading it being a "Factory only submitter" will not harm ;-), submitting to SLE: To make all our life a bit more easy, please consider to review the following page: https://en.opensuse.org/openSUSE:Packaging_for_Leap There is already a table with "Agreed differences from Factory". Please use this table, if your package needs to drift away from Factory in SLE. The reviewers will use this table during the review - and Marketing might use it as well for release-notes later. - A note about Changes files - We also noticed that some use the opportunity that SLE-15-SP4 will be a feature release (including new package versions and features), to jump with their SLE package on the version in Factory. While we see this as a good step in general, we often see differences in the .changes file. We decided to accept such differences - with a few exceptions. Most important are: * bugzilla references are kept * CVE references are kept * Changelog stays in chronological order * patches added/removed with the new submission While this might result in more work in the beginning (and additional changes entries for keeping bsc# or CVE numbers), there is meanwhile a lot tooling around these bsc#, boo# and CVE numbers. This tooling might break and give everyone headaches in a few years, if we need to check if a bug or CVE is already fixed in the current package version. So feel free to take your Factory package and submit it to SLE. But please review the old package in SLE-15-SP3 before and grep out all the bug- and CVE numbers. Those, which are missing, can be added as new changes entry. - Get in touch - And finally: if submitting a package to Factory or SLE via osc - please remember that you have the chance to inform the reviewers via the comment for this submit request. The comment (which is create by calling 'osc sr') per default just contains a copy of the last changes entry, but this can be changed. Feel free to inform the reviewers about your big changes upfront, so they don't need to decline the package first. Knowing, that a changes entry has a big diff by intention - or that you rewrote the whole spec file - gives the reviewer a good feeling, that your submission was not done by mistake... with kind regards, Lars