Overview
Not sure I understand. Remove btrfs-subvolumes.patch ([fate#316134](https://features.opensuse.org/316134)): is mentioned in change from Jun 14 already. I also didn't see a specifc shadow version at SUSE:SLE-15-SP3:GA. So I'm guessing it uses the old one. Could you explain what we are trying to sync here? Thanks! :)
@sbrabec If you want to add bug#, fate# etc to sync with SLE, you can just go ahead and modify the old entries where it makes sense.
Actually, a single changes entry was explicitly requested by SLE/Leap maitainers, and the update was rejected without it.
Yes, I can add bug# to entries below. But I had to summarize all Leap 15.2 -> 15.3 changes in a single entry. So people who want conscious update don't need to read lots of entries.
Spreading those entries over more entries (in case of util-linux ~ 10) would make such review much more complicated.
Please give a link to rejection so I could read up? This, in this form does not make sense. Also see https://en.opensuse.org/openSUSE:Creating_a_changes_file_(RPM)#Cross_Service-Pack_merges_for_SLE
@jubalh the submission is to retain the bug# and fate# for a SLE 15 SP3 submission of the package. A submission of this new shadow version is planned for 15 SP3.
Thanks for clarifying.
It appears to me that the second entry is not needed then (- btrfs-subvolumes.patch: implement support for creating user home
+ directories on btrfs subvolumes (v4.7, [fate#316134](https://features.opensuse.org/316134))) since the fate nr is mentioned in:
```
Wed Jan 23 09:35:01 UTC 2019 - adam.majer@suse.de
- btrfs-subvolumes.patch: implement support for creating user home directories on btrfs subvolumes (fate#316134) ```
already.
And wouldn't it be nicer to just add [bsc#1141113](https://bugzilla.opensuse.org/show_bug.cgi?id=1141113) to the old entry (Fri Jun 14 06:20:46 UTC 2019) that updates to shadow 4.7?
I think it would be cleaner this way. Then the old entry would contain all the relevant information and we don't have a (maybe) confusing "empty" entry in the changelog.
Actually, a single changes entry summarizing changes since 15.2 and dropped patches was explicitly requested by SLE/Leap maitainers, and the update was rejected without it.
I selected this format, as I had to do the same for util-linux, and in that case half of 15.2 patches never existed in Factory. (So mentioning a patch that never existed would look strange.)
I was tempted to skip patches that were mentioned below, but later I realized that it could result in even less readable changes. So I decided to skip only changes entries that were exactly equal for both Factory and SLE/Leap (i. e. the same date, same text, same bug # and the same patch), and summarize everything else.
To be more verbose:
I had to go through many changes in both shadow and util-linux.
I divided these changes to 3 groups:
Patch existed only in 15.2, not in Factory. It is mandatory to mention such patch in changes, but there is no corresponding changes entry in Factory changes.
Patch existed in both 15.2 and Factory. It is mentioned, but the context is a bit different. It was already removed in past, e. g. 2 years ago. The patch is already mentioned, so it is not mandatory to mention it again.
Patch exists in both 15.2 and Factory. It is mentioned, the context is equal. The patch is already mentioned, so it is not mandatory to mention it again.
Point 1. creates a madatory request for a dummy entry. 3. can be cleanly skipped, as the same changes entry already exists.
Point 2. is questionable. I tried to mention only patches type 1. in the dummy entry. But it is IMHO even more confusing. In the opposite, not mentioning 3. is not confusing, as such patch or fix just continues to exist and does not need to be explicitly mentioned.
That is why I decided to mention all removed patches and fixed bugs in the dummy entry, whether they existed in Factory or not.
@adamm, @jubalh, @netsroth: review reminder