12:28 a.m.
ellert reported a new issue against the project: `releng` that you are following:
``
Hi!
I tried to reopen #14751, but it was automatically reclosed again without anyone answering
my questions. So I now open a new issue instead hoping fir o more pleasant experience.
I restate my questions below:
Why is there a "Adding package.cfg file" commit on this branch?
What is its purpose?
I find this commit very disruptive and would prefer it not to be there, can someone please
remove it?
What mistake did I do to trigger this commit to be added?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8582
11:21 a.m.
kevin added a new comment to an issue you are following:
``
This is definitely a bug. I am not sure where, but I guess in fedscm-admin tool.
Ah, already fixed upstream:
https://pagure.io/fedscm-admin/c/b5976d1ae92184f1f1f9ee1c7f69916d5e624883...
@limb can you make sure to use fedscm-admin with this patch?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8582
11:22 a.m.
limb added a new comment to an issue you are following:
``
Will do. Any updates on my PR?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8582
11:23 a.m.
limb added a new comment to an issue you are following:
``
Huh. I think mine does have it actually.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8582
1:32 p.m.
ellert added a new comment to an issue you are following:
``
Do I understand it correctly that this commit shouldn't have happened on an epel 7
branch, but that such a commit would have been expected on an epel 8 branch? It would be
equally disrupiive there...
Can the commit be removed since it was added in error?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8582
1:37 p.m.
kevin added a new comment to an issue you are following:
``
Do I understand it correctly that this commit shouldn't have
happened on an epel 7 branch, but that such a commit would have been expected on an epel 8
branch?
Yes.
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)
Can the commit be removed since it was added in error?
No, we don't remove commits. You can just remove it in a further commit.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8582
11:36 p.m.
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
9:30 a.m.
smooge added a new comment to an issue you are following:
``
The workflow you are describing is not universal and some maintainers would find it
completely antithetical to what they do. Even people who keep the same spec file are not
looking to keep every branch 1:1 in order. What you seem to be describing is that you
really don't want your software ever branched (since you find other people adding
fixes to other branches inconsiderate) and just want 1 tree to work from and track.
However that may be me putting words in your mouth.
In any case, I am not sure what you are wanting. No one to touch your branches ever? Some
other solution? If that is the case, I would say you need to bring this up with FESCO as
they need to clarify what we can do in EPEL branches in the future.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8582
10:43 a.m.
ellert added a new comment to an issue you are following:
``
From what I understand the purpose of the package.cfg is to make it possible to build
packages for the epel-playground repo from the epel branch.
If you are not going to build for the epel-playground repo, you then should remove the
file to make sure there are no accidental builds done for the epel-playground repo.
If you are going to build for the epel-playground repo the reason for this is that the
package in epel-playground is different from the package in epel, and should be built from
different git branches, and you should remove the package.cfg file to make sure that all
builds for epel-playground repo are done from the epel-playground branch, and not
accidentally from the epel branch.
So in neither case the package.cfg file is useful.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8582
12:06 p.m.
smooge added a new comment to an issue you are following:
``
The idea was that it should by default build against both el8 and el8_playground. This way
a person can enable el8_playground and get as many packages are in el8.
This was to deal with the times when EL-8.n comes out and we aim playground against the
latest and the regular el8 against the last el8.n-1 repo. That way a mass rebuild or some
other problem could be done in el8_playground as we could find all the packages needing it
versus trying to cherry pick what problems might happen as we have with former epel
releases.
I am not saying this is the one way to accomplish this but this was what we found to be
workable at the time. If you have a better solution, please let us know.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8582
1:22 p.m.
ellert added a new comment to an issue you are following:
``
You plan is to use the epel-playground repo for two very different and incompatible
tasks.
The first usecase is as a playground where maintainers can try out new versions and new
features. This means that the versions of packages in the epel-playground are allowed to
be different from the versions in epel, might have additional features enabled that the
versions in epel are missing, and occasionally could even be backward incompatible with
the version i epel or have a different soname for libraries.
The second usecase is as a place to do mass rebuilds for new rhel point releases, where
you plan to change the rhel base to a new point release in epel-playgroind, do the
rebuilds in epel-playground, and the when you change th epel repo to the new point release
merge the mass rebuilt packages back to epel. But, since the use case for the playground
repository was to be a place where new unstable stuff is tested, all those rebuilds will
have been built against these new versions and might depend on features that are not
provided by the dependencies that are in epel, or be compiled to depend on a different
soname than the library that is available in epel.
I.e. since the playground is a playground, packages built in the playground must never be
merged into main epel.
In Fedora there are rebuilds all the time. For new python versions, for new perl versions,
and the recurring mass rebuilds. These are done in side tags. This can be done without
adding a package.cfg file allowing the build of the package in the side tag, but koji
allows this by default.
The proper way to do a mass rebukd for epel8 is to declare an epel8-rebuild sidetag that
inherits from the rhel 8.n+1 and epel8 and definitely must not inherit from
epel8-playground. The packages built in this sidetag can then be safely merged into epel8,
when epel8 is redefined to inherit from rhel 8.n+1. And since it is a sidetag there should
be no need to add any special package.cfg since this is not needed for sidetags in
fedora.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8582
2:09 p.m.
smooge added a new comment to an issue you are following:
``
OK at this point I think having this conversation in a ticket is not going to help get the
viewing it needs. Could you please bring this up on the epel-devel list so we can get a
wider view of the problem and resolve it.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8582
1722
days inactive
1726
days old
rel-eng@lists.fedoraproject.org
11 comments
4 participants
participants (4)
-
Gwyn Ciesla -
Kevin Fenzi
-
Mattias Ellert
-
Stephen J Smoogen