Dne 25. 03. 20 v 15:02 Zbigniew Jędrzejewski-Szmek napsal(a):
On Wed, Mar 25, 2020 at 02:06:59PM +0100, Aleksandra Fedorova wrote:
> Hi, Miro,
>
> On Wed, Mar 25, 2020 at 1:28 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>> On 25. 03. 20 12:49, Aleksandra Fedorova wrote:
>>> I think that not having eln-branch is very important part of the
>>> concept as we don't want to fork Fedora. By using conditionals in spec
>>> files we do create variants of the rpm, but at list we get them
>>> automatically synced with the upstream sources. So whenever you update
>>> the package in Rawhide, ELN binary package is updated too.
>>>
>>> Conditionals create problems indeed, we should use them carefully. I
>>> would prefer if instead of conditionals we find ways how to make
>>> Fedora packages more flexible, change from Requires to Suggests for
>>> example, or split into subpackages.
>>> But in this case I think conditionals are a much better choice than
>>> branching, as when done once, they require less maintenance on their
>>> way to downstream.
>> Sure They are good for downstream. RHEL clearly benefits from this.
>> But they impose additional cognitive overhead on the community maintainers in
>> Fedora.
>>
>>
>>> We add conditional in Rawhide, we inherit it in branched Fedora, we
>>> consume it in CentOS Stream, we get it in EPEL. All of it happens
>>> automatically once we have the ELN compatibility in Rawhide.
>> This is all nice only as long as you prefer conditionals over branching. For a
>> Fedora maintainer who doesn't, this is just "unnecessary cruft" in
the spec file.
> It is not really about personal preferences. These are two different
> approaches with different purposes, different results and different
> requirements.
> There are consequences on choosing one other the other.
>
> Branching means forking Fedora Rawhide into something else. Which
> eventually will lead to new downstream tree which will ignore the rest
> of Fedora and just use the fork instead. It can be done, but I think
> it will damage Fedora as a project.
Just FTR, there is `git symbolic-ref` [1], which means that the "branch"
won't need to be necessarily branch, if the content of master and
rawhide is the same. In that case, you don't even need any
synchronization. Given this, it would be easy to track how many packages
are vanilla Rawhide packages and which are modified and need special
attention.
But this is of course just implementation detail.
Vít
[1]
https://git-scm.com/docs/git-symbolic-ref
IMO, that significantly overstates the difference between the two.
In particular, branching is exactly what happens every six months when
we start a new release, and yes, it is possible for the branches to
diverge, but no, it is also possible to keep the branches synchronized
and actually for many packages this is what happens.
For any specific package, whether the branches are similar or divergent
depends on the situation of the package and maintainer choices.
Also, a side note: with the planned changes to do away with changelogs
and release tags in .spec, branches have the potential to become identical
(i.e. we would still have branches, to know what to build where, but they
would point to the same commit).
Heavy ifdeffery in spec files is something of a past. Different
maintainers have different preferences, but I think it is fair to
say that we have moved significantly in the direction of simplified
spec files and less conditionals.
I think you shouldn't discount the separate branch approach just yet.