Re: ELN SIG First Meeting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux