On Thu, 3 Oct 2019 at 11:20, Vít Ondruch <vondruch(a)redhat.com> wrote:
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.
Which point? You have had multiple. The one where you say doesn't
follow the procedure does not stand.
--
Stephen J Smoogen.