Re: ELN SIG First Meeting

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

 



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




[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