On Tue, Aug 13, 2019 at 5:22 AM Mattias Ellert <mattias.ellert@xxxxxxxxxxxxx> wrote: > > Hi! > > I recently had a discussion about the use of the playground on > pagure.io: https://pagure.io/releng/issue/8582 > > I was asked to bring the discussion here to epel-devel. > > I quote my last comment from the thread below. If you want more details > you can read the entire thread at the pagure link above. > > > 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. > > Mattias 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. 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. 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. Troy _______________________________________________ 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
