On Thu, 2021-03-04 at 16:24 -0500, Matthew Miller wrote: > On Thu, Mar 04, 2021 at 01:11:55PM -0800, Kevin Fenzi wrote: > > In any case, I'm not convinced mass branching is ever going to work > > for > > epel. Although I suppose as more packages have the epel packager > > sig > > group on them, that group could work on faster adding piles of > > packages. > > Perhaps we should try and identify all the 'please branch for epel' > > requests in bugzilla and have some way for the epel packager sig to > > step > > in and get those added? > > I have a couple of packages which I find handy to have in EPEL -- > little > command line utilities, mostly -- and which have very little change > over > time and which I'm 99.9% will just build on EPEL 9. My EPEL > maintenance > policy is basically "build once when there is a new EPEL, plus also > in the > rare chance of an update which seems significant, or if someone > asks". > > > So for me, having these automatically branched and auto-built (once) > whenever there's a new EPEL would be ideal. > Sorry for jumping in late, I'm sporadically online while on parental leave (haven't been able to touch my laptop for the past few days!) Mass-branching does seem too different from what we currently do (EPEL branches are opt-in for a package); building in COPR sounds more workable (Miro does mass-rebuilds of Python packages to test for compatibility with upcoming Python releases that way). Selecting which packages to build is tricky though - we wouldn't necessarily want to mass build packages that will never be packaged in EPEL, as that will just be wasted cycles. And we have packages that are in EPEL for various reasons: - the package itself is useful to end users (e.g. tools as Matthew mentioned, but also libraries that might be dependencies for some software that is itself not in EL/EPEL - the package is a dependency of a package that is useful -> in this case, automatically branching might not be a good idea if e.g. this is a parallel installable new version of a library already in EL, and for ELN said library is not needed How about this approach, though? - create epel(N+1) (and epel(N+1)-next, now that we're doing Stream first) as soon as ELN starts targeting EL (N+1) - so in this case, we want to create epel10 / epel10-next now - if said branch exists for a package: - if a spec is found, use it for building against ELN - if a spec is not found, build the Rawhide branch against ELN Maintainers interested in EPEL can thus get early notification as to if they need to make any change (or if they need to chase missing dependencies and get those branched) This will tie in nicely with what the EPEL Packagers SIG is working on - we want to have the SIG eventually be added as collaborators (on epel* branches) to packages where we identify a need for EL use, but where the primary maintainer is not interested: having the branch available earlier will reduce the need to scramble at the last minute to chase packages' dependencies. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/michel@xxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
