On 8/13/19 7:29 AM, Troy Dawson wrote:
I was not aware that we were using playground for the second usecase.
I thought the discussions we had in our weekly EPEL Steering meeting
we agreed *not* to use playground for rebuilding, but had agreed to
use side-tags. If I was wrong, could someone please point me to the
document that says we do.
No, you are right, that is not a usecase we had for playground as far as
I am aware.
Honestly, the package.cfg reasoning is rather vague to me. I'm
not
sure where it came from. I don't remember being asked about it.
It was in the playground discussions...
Personally, if I had been asked I would have said that at the least,
it needs to be .package.cfg. This is done in several places in the
Red Hat Brew dist-git, and it stops alot of these types of
discussions.
But I also didn't fight against it. Why? Because I knew the first
thing I was going to do was delete it. And ... that's what I've done.
Unfortunately, the way I've deleted it (git merge f30) seems to create
a freighter boatload of emails to various people (who are not me).
But the end result is that for a majority of my epel8 dist-git repo's
are in sync with f30. Are they "perfectly" in sync? Well, I guess
according to what you define it, no, but I am able to do a "git merge
<branch>" and it merges without any issues. That's what I care about,
and I bet in the end, that's what you care about as well.
Yeah. So on thinking about it, we could instead document that you need
to always enable epel8 with epel8-playground. Then, packages not built
for playground will just be in epel8 and it would get them from there.
Or we could try and do something with pungi that also gathers from
epel8, so epel8-playground would have all the epel8-playground packages
+ all the epel8 packages in it. (but that would use more disk space).
kevin