On Thu, Mar 04, 2021 at 02:31:14PM -0800, Michel Alexandre Salim wrote: > 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!) No need to be sorry. :) Congrats! > 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 What makes the list of packages there? Everything in epel8? Everything in fedora? The build ordering there would be difficult to know and definitely require people work. > 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. Well, perhaps. But also it means they have to maintain another branch (epel10) for like 3 or so more years, no? Deps in eln will change, things will be added, etc. I think avoiding a last minue scramble might be nice, but making it a 3 extra years of maint is... a bit much. 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
