On Sat, Mar 13, 2021 at 05:09:44PM -0800, Troy Dawson wrote:
>
> Sorry for coming late to the discussion. I took a week off and all
> sorts of things happened while I was gone.
That fast paced open source development. :)
> I believe Kevin and Smooge, and possibly even you Davide got this
> backwards. And I think if we do this right, this can be a thing.
>
> When we started ELN, one of the major promises was that it wouldn't
> interfere with regular Fedora work. That your average Fedora packager
> that didn't care about ELN, could continue to not care about ELN and
> nothing would change.
> I believe we (ELN SIG) should extend the same courtesy to EPEL and the
> EPEL community and packagers.
Do note that this isn't really the case currently, although I agree
thats the goal. Due to limitations of our notification system, Fedora
maintainers are getting build notices and such from ELN builds.
Or course hopefully we can fix that.
> The email discussion went in the direction of all the work that EPEL
> would need to do to create an ELN EPEL. But we (ELN SIG) shouldn't
> have expected that. We should have expected to do all the work.
>
> So, if we flip this around, where everything is on ELN, how would that work.
>
> We create a new Fedora target and tag: eln-extra (so people do NOT
> confuse it with real EPEL)
> eln-extra-build inherits from itself and eln-build
> If a package is built against the eln-extra target, and it is
> successful, it gets tagged with the eln-extra tag.
> There is a daily (or some other time period) repo creation. No
> images, just a repo, like epel.
Could be composed with eln? I think eln composes every 4 hours or
something?
> There is a list of packages, similar to the list of packages used to
> create the ELN list, on some github/gitlab/pagure repo. If you put a
> package on that list, you associate your name with that package.
> Just like ELN, when a package on the eln-extra list gets built in
> rawhide, it get's built in eln-extra. In fact, it would be best if we
> just altered the ELN trigger/periodic scripts to look at this list
> along with the regular ELN list.
>
> What are people's thoughts on this?
> No extra work on EPEL.
> If someone, or some company wants to test ELN and need packages not in
> ELN, they can add the packages to the list, with their name/company
> associated with that package.
> It would get built, put in the repo, and they can then run their ELN
> test with the package they need.
>
> Thoughts?
My concern is again maintainers/maintainace.
If there's problems building in eln-extra it either means the Fedora
maintainer(s) have to fix or at least review PR's for rawhide to fix the build
or the eln-extra maintainer(s) have to be co-maintainers or
provenpackagers.
ok, lets fast forward to when CentOS 10 stream exists. I'm guessing
there's going to be a push to mass branch all the things in eln-extra
for epel10-next? Again, who's maintainer there, the eln-extra maintainer(s),
or the fedora/epel maintainers?
And then there's when RHEL10 is released, and epel10 can exist. Mass
branch those? who is maintainer?
I'm not sure this is all a super big deal, but I'd really like to make
sure we make _very_ clear who is responsible for what. Some maintainers
would be happy to maintain for that long cycle (from landing in
eln-extra now, to epel 10 next, to epel10... thats what... 13 years?),
but some may not, and some might be happy for part of it but not the
entire thing.
Anyhow, I like this proposal much more than early epel10{next}
branching. :)
kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
