On Tue, 2021-03-02 at 08:38 -0500, Stephen John Smoogen wrote: > So mainly a package maintainer only worries about what is deployed at > their workplace. And I would guess from the size of unanswered bugs > and other things, some of these maintainers did a one-time build to > get what they wanted and went onto other things. Others would update > things until it could no longer build with older RHEL-6 or 7 code and > stop maintaining it. This is where i get most of my answers.. > someone asks 'why is it not in EL-?' and I go ask the maintainers. > Usually the Fedora maintainer is like 'I don't use EL and don't want > to unless paid to' and then I find on the list of co-maintainers who > might be an EPEL maintainer. This usually gets the answer of 'look we > are a EL-6 or EL-7 shop and I can only really do it for that. Can you > find someone else?' Then someone eventually volunteers, we find out > they aren't a packager and have to go look again. Eventually we get > someone who is a packager who gets added to the packaging list for > that package and takes over that branch. > > Since EPEL was not really a major thing the Fedora maintainers or the > base community have wanted to invest in, there has been no drive to > do more book-keeping than what is needed to keep the system going. We > could track EPEL/non-EPEL maintainers in the package database system > and now we can track some level of control in pagure I believe but it > has been pretty much 'is it there? good.' Thanks for the clarification, this is helpful. I think if we could better track who maintains which release that would definitely help down the road, both for this effort and in general. Another thing to consider is allowing maintainers to say "I don't care about EPEL" outright, and then streamlining the process of branching those packages for EPEL if someone interested does show up (e.g. via the EPEL Packagers SIG). > up to 8 full time people for basic packaging, builds, dealing with > bugs, etc. [This is going on a decision that packages being > 'maintained' are only at 'it built, ship it' quality. If we need > higher levels then you will need more staff.] > 4 people to do documentation, upkeep and other management duties of > keeping things on track > 4 people to work through QA items and actually figure out tests > relevant to EPEL. > 6-8 people to design and work with the koji upstream to fix the > fedora build system to work with two different modularities. > Currently MBS can only build a limited type of modules which is what > is breaking PHP and I think perl apps. Are these MBS limitations documented somewhere? I'm not terribly familiar with this part of the infra (nor with modularity in general). > The work plan would be that most of the first 6-8 months would be > that last group working on getting a build system which works for > EPEL. Because EPEL uses a koji 'hack' to get to the RHEL binaries it > does not 'know' really what those packages are in the same way it > does for packages it built itself. The same goes with MBS. This means > that you have to come up with a way to fool them into using the > proper modules when they are needed etc. HOWEVER you also have to not > break the Fedora build system at the same time so that fedora > packages can continue to build. At the middle of the initial period > it would be either done or found to be outside of easily possible and > some other system would be needed. At that point it is either finish > it up or build a new system. > > The package branching/building/qa can go on for a subset of packages > but some will be impossible because of the modularity problem. > > After either of the systems are in place, a planning period goes into > place on how to build out modules and for what. There are some things > which make sense (PHP, python, ruby) and then there are specific > complicated apps which make sense. However there need to be > consistent rules, documentation on how to do it, and training to make > them. Also a consistent testing process would need to be done. > > By the time this is done then it will be time to work on the next set > of EL branching > > [I had an older proposal which went over the above but undercut the > number of people needed.. when we tried this with EPEL-8 it was > overwhelming at 1/2 the staff numbers so I am hoping I am getting > this right at this level.] Ok, this would definitely be a major effort, both in terms of manpower and of disruption to the infrastructure. It seems unfeasible to go down this road without resourcing and wide buy-in that this is the way to go. > I do see the need for this, but I really think this might be the > straw which broke the camel's back. ELN is already getting a lot of > pushback because the tools send regular failure notices to > maintainers who have nothing to do with ELN. Adding in 10,000 more > packages would basically push a lot of maintainers past the breaking > point. There is also the fact that ELN-EPEL would be building these > against s390x and p64le on builders which are basically overloaded > already and you don't care if you got a package from. Maybe there could be a middle ground here. What if we scoped things down just to packages that have explicitly opted in. The maintainer could set a "automatically branch EPEL" flag, and we'd add an ELN- tracking branch (based off Rawhide) and the appropriate EPEL branch when the time comes. The benefit here is that we could set restrictions from the start to try and keep things sane (e.g. exclude packaging involving modules). > It would also not drive a 'fix' to the problems of where this package > goes from being in ELN and is now in RHEL so the Fedora build system > no longer 'knows about it'. So you would find that when EL10 came > out, that the EPEL system would be 'broken' in many ways not covered > by the ELN testing. In this case though, wouldn't the package just end up coming from the RHEL / CentOS Stream side of things instead of from EPEL proper? 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
