Dne 03. 10. 19 v 15:56 Miro Hrončok napsal(a):
On 03. 10. 19 15:23, Vít Ondruch wrote:
>
> Dne 03. 10. 19 v 11:58 Kevin Kofler napsal(a):
>> 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.
>
>
> It depends how you maintain your packages. My guess is (and I am sorry
> if I am mistaken) that you don't follow the
>
>
https://fedoraproject.org/wiki/Updates_Policy#Philosophy
I do.
> If you followed this policy, then you would touch the stable branches
> just rarely and therefore keeping them fast forwardable would be just
> waste of time.
I touch stable branches for bugfix upgrades.
But this sooner or later means rebase in Rawhide and just applying
patches in the stable branch. So my point still stands.
Vít