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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
