On Sun, Aug 30, 2020 at 11:44 AM kevin <kevin@xxxxxxxxx> wrote: > > On Fri, Aug 28, 2020 at 03:11:49PM -0700, Troy Dawson wrote: > > > Pros for building against stream: > > > - We would have a way to test EPEL packages that matter against the > > > not yet released RHEL version. > > > -- How often would this matter? > > > -- It's hard to say. There might not be a single EPEL package needing > > > this for the entire RHEL 8.3 release. > > > -- I know for the 8.2 release, I would have liked it so I would have > > > had a place to let others test my updated KDE. > > > --- But I found a work around, so I didn't have to have it. > > > > > > Cons for building against stream: > > > - I think you've hit on a big thing. For those wanting a major > > > change, but don't care about stream, then playground becomes useless. > > > -- So this cuts down on the usefulness of playground. Packagers who > > > want a major change in their package, and are working on stream. > > > - HERE IS THE BIGGEST CON AGAINST USING STREAM > > > -- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes > > > out. At some point after that, it switches to being based off RHEL9. > > > --- This means that infrastructure is going to have to switch > > > everything back to being built off RHEL. > > > --- We will have to re-document things. > > > --- More confusion if we had go the CentOS Stream route. > > > > > > Troy > > > > At the EPEL Steering Committee Meeting, this was discussed again. > > I believe we all agree that having -playground build off Stream isn't > > a good thing. > > But we are also concerned about possible library changes in RHEL8 that > > might affect EPEL8 packages, and having something based off Stream > > would be good. > > Here is the proposal. > > Note: A) was re-written with better wording than above. > > > > A) epel8-playground > > 1 - Manual builds only. No package.cfg files. No automatic builds. > > 2 - Assume playground depends on epel8. > > 3 - Built off RHEL8 and CentOS Devel, just like epel8 is built. > > > > E) epel8-next > > 1 - Manual builds only. No package.cfg files. No automatic builds. > > 2 - Assume -next depends on epel. > > 3 - Built off CentOS Stream. > > 4 - Has a limited lifetime that corresponds with the CentOS Stream / > > RHEL lifetime. > > -- In other words, after CentOS Stream switches from RHEL8 to RHEL9, > > then epel8-next get's archived. > > > > If people are wondering about the name, it was decided to use -next > > instead of -stream, due to the overuse of 'stream' among other > > reasons. > > > > Thoughts? > > Well, I think it satisfies all the use cases, but... we barely have > enough cycles to try and revamp playground. Do we think we have enough > to do that and also make a new -next version? > Very good question. Without being a superhero, do you and/or Smooge think we have the resources to do this? It's sounding like the answer is no. > Also, if we do make it, perhaps we should think what critera we would > use to determine it's successfull? 10 packages using it? more than 1? > Perhaps we could gather a 'I would use this' list from maintainers > before we implement it? Also a very good question / idea. Any ideas on what would be a good way to ask that? Asking on epel-devel would get some. Asking on epel-annouce would get more, but if we did that, we'd have to have the answers not come back to that list. Possibly cross post to fedora-devel and/or centos-devel. 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
