Miro HronĨok wrote:
On 03. 10. 19 1:32, Kevin Fenzi wrote:
> I'm not sure how to handle the dychomoty between having different spec
> files for each release and wanting to maintain just one spec that has a
> bunch of crazy conditionals in it. Even thought I do this too, I think
> we need a workflow that discourages this somehow.
I believe that moving release tag and changelog entry to annotated tags
solves this problem (or makes it insignificant).
It means you can just cleanly cherry pick a fix anywhere it is relevant
(most of the time) instead of fighting the changelog conflicts all the
time.
I don't understand the people actually maintaining different changelogs for
the releases. I just merge master into the release branches when I push an
update, and if that includes some changelog entries for Rawhide-only mass
rebuilds, so be it. Removing them is not worth breaking fast-forwardability
of the branches.
I even go as far as reverting branch-only commits and then doing the
bidirectional merge trick to restore fast forwardability. That of course
clobbers the branch-only changelog section and replaces it with the one from
master, but that's just how things are. Again, I think fast-forwardability
is more useful than per-branch changelogs.
Kevin Kofler