On Mon, 2021-03-01 at 15:49 -0500, Stephen John Smoogen wrote: > That would require a lot of changes in both EPEL and in Fedora. In > Fedora there is a general expectation that if a 'branch' is active > then it is maintained by someone.. usually the primary maintainer. > Many Fedora maintainers are only interested in maintaining packages > in the latest release. THis is why the ELN packages are being > 'watched/maintained' by the ELN team and sig. Maintainership usually > means dealing with bug reports, build failures, etc which can take up > a good amount of time. That's a fair point. To be clear, I would not expect this to happen by itself -- it this idea turns out to be feasible, I would be happy to pitch in and/or try and find resources to help with this from my end. > This is part of the reason why EPEL packages are not auto-forked for > each EL release. Most maintainers are only interested in supporting > maybe EL-6 or EL7 and we need to find someone new to do the EL-8 > branch. Interesting, I had not realized this was the case. My (likely naive) assumption was that if there's an epelX branch for a given package, there would likey be an epelX+1 too, and when that wasn't the case it was mostly because the maintainer hasn't gotten around it yet or nobody had asked. My assumption was that by providing a readily updated "epeln" branch we would save the maintainer some of this work. Are you saying that for some packages it is expected that the maintainer would only care about say epel7 and not epel8? In that case, do we / would we track the maintainer for epel8 specifically somewhere, if one were to volunteer? > We would need to have a dedicated team of people to do this with ELN > related items. We would also need to have additional build and > storage resources to deal with these artifacts, not alone the growth > of 'just need this' packages. Is there an easy way to ballpark estimate the resource demand that an effort like this would require? > When I was trying to make EPEL-8 1:1 with EPEL-7 I found I was having > to add more and more packages just to get the new build 'requires:' > done. I stopped around a thousand 'new' packages to the tree when I > was reminded that we don't do automatic branching for EPEL. I really > don't know how many packages would be needed to make it work, but do > know it is a full time job to get set up and keep going. While ELN is > probably 4000 src.rpms we would be looking at needing to > build/rebuild double that for EPEL. Ah, that's fair. I hadn't thought about potentially neededing to branch extra packages to meet new build dependencies, but you're absolutely right, that would be a major issue here. I should probably expand on why I'm thinking about this in the first place. I want to use ELN as a proxy for the next CentOS Stream release to streamline its qualification on our infrastructure. The idea being that if we can continously test ELN on a small subset of production, that will detect potential issues early on, allow us to get ahead of policy changes that might require internal work, and hopefully surface bugs that we can report and fix upstream long before branch time. However, we use EPEL a lot in our infrastructure, to the point that I suspect it would be difficult to do a meaningful prod-like deployment with ELN alone. I could probably hack something around this, but I figured it'd be worth to see if we can build a generic solution instead that could benefit Fedora and CentOS upstream, rather than something Facebook specific. To be clear, I'm aware that this would require work and resources within Fedora, and I'd be happy to help with both as needed if this is deemed feasible. Cheers Davide _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
