ellert added a new comment to an issue you are following:
``
> It would be equally disrupiive there...
How/in what way? It's needed in epel8 branches to keep epel8 and epel8-playground
builds in sync (until/unless you decide to diverge them)
It completely breaks the normal package maintenance workflow.
The traditioanal way to maintain a simple package that can use the same spec for all
releases is to keep all branches in sync. That is, commit changes to master and merge
master into the other branches. Occasionally a proven packager or releng slightly
inconsiderately would add a commit to a non-master branch. The maintainer then needs to
recover by merging this commit from the branch into master and then from master to all the
other branches.
This way of cleaning up would not work for this "package.cfg" commit, since it
would add a config.cfg file that is very branch specific to all the other branches. This
is what I mean with disruptive. In order to recover here, the maintainer would have to
first add a revert commit on the epel branch and then merge the epel branch to master. But
what was the point of adding the commit then, if the first thing that must be done is to
revert it.
Why would you ever need to build anything for playground if it is "in sync" with
the non-playgrouynd build. The only time you need to build for playground is if it is
different in some way, so you only need to build for playground if it is not "in
sync". So there is never any need for keeping the playground build in sync with the
non-playground build - so the package.cfg file solves a non-existing problem. Why add it
then?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8582