On Sat, 2021-03-13 at 17:09 -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. > > 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. > > 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. > 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? Thanks Troy for taking time to put this together. I like this plan: it solves my usecase and it doesn't put undue burden onto EPEL or the individual packagers, while also leaving open the possibility of leveraging eln-extra to seed the next EPEL release if a packager so desires. How would be manage in practice the maintainership of packages in eln- extra? Would it be recorded in dist-git (coupled with the relevant ACLs to allow pushing fixes if needed), or somewhere else? 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
