On Fri, Jan 29, 2021 at 01:46:56PM -0800, Troy Dawson wrote: > On Fri, Jan 29, 2021 at 2:29 AM Petr Pisar <ppisar@xxxxxxxxxx> wrote: > > > > On Thu, Jan 28, 2021 at 03:15:29PM -0800, Kevin Fenzi wrote: > > > I think that could be workable, but I'll toss out another proposal: > > > > > > As soon as centos 9 stream exists, we create epel9-playground and allow > > > people to branch/add packages to it. Once rhel9 is GA, we setup epel9 as > > > usual and epel9-next and point epel9-next to build against stream and > > > playground to build against rhel9. > > > > > Do you know what CentOS 9 Stream will look like between its first availability > > and RHEL 9 GA? I worry that there will surface RHEL 9.1 changes. Then > > switching epel9-playground from CentOS 9 Stream to RHEL 9 could manifest > > incompatibilities as the build root would regress. To be clear if the question was directed at me: I have no idea. ;) > Very good question Petr, and thanks for asking it. > I asked internally about this. > There will be a set time [1] when RHEL 9.0.0 release will be branched, > and all the final stabilizing stuff will happen internally. > At that point, CentOS 9 Stream will be on the 9.1.0 release, and any > changes to it will not be in the 9.0.0 GA. > I don't know when that point in time is, I haven't figured it out yet. > But my educated guess is 3 months before GA, if I'm wrong, then I > don't think more than 6 months before GA. > > So, that gives us something to consider. Do we think that 3 to 6 > months of possible changes will affect us too much? > Troy > > [1] - I wasn't given a date, just X weeks into the schedule. We talked about this in the meeting yesterday some. Pondering on it I think the best was forward would be: * as soon as centos 9 stream exists and is consumable, we setup things and start allowing epel9-next branches (only) for things. We could do this as we plan for epel8-next (ie, bodhi, updates/updates-testing) or we could decide thats too much overhead and just do a daily compose of everything. The first option would be more up-front work, but then we don't have to change it later. * as soon as rhel9 GA is available and consumable, we setup things and start allowing epel9 branches. We also send a note to all 'epel9-next' maintainers that epel9 is available and that they should request that and build there. If we did epel9-next as a 'rawhide style daily compose' we would switch it to bodhi/updates-testing then. I'm not sure what to do about rhel9-beta. My first thought is to ignore it and tell people to use epel9-next with it, and consider following stream to get updates. As for epel9-playground... I'm kind of coming to the idea that it's not that useful really and we shouldn't make one for 9. SO, I guess this is all just the orig proposal. ;) kevin
Attachment:
signature.asc
Description: PGP 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
