On Mon, 2020-09-14 at 08:54 -0700, Kevin Fenzi wrote:
I'll add that in addtion to some maintainers not wanting to
their fedora packages also in epel, the timelines involved sometimes
make it so a package that was branched/maintained in epelX, makes no
sense in epelY. ie, Xfce 4.14 would be fine now, but in 3 years, 4.16
whatever would make more sense and the package set may well not be
Right, that's also a good reason for why branching by default is not a
good option for all packages.
I wonder... could we somehow let maintainers indicate "I want
branched for the next epel as soon as it's available"? I suppose in
thats what adding epel-sig would do? With the addition of 'epel-sig
should build by packages as soon as those branches are ready'.
I wonder if these are two separate concerns though? I agree that being
able to indicate a package should always be branched would be great,
but... epel-sig / epel-wranglers might not find a package relevant in a
new EL release (e.g. say we care about neovim, and want to carry it by
default in new releases, and thus we also care about some of its
dependencies that are not in (RH)EL core -- but the set of dependencies
we care about in EPEL7 != the set in EPEL8 etc.
^ if that seems explicit that's because it, uh, is from personal
Maybe package.cfg might be where such a metadata live? e.g. if the
epel8 branch of the package has a package.cfg that says "branch for
next release" it gets branched for epel9 -- and inherits that
package.cfg by default. If a package gets opted in once and at some
point is no longer needed in the next epel, just delete that.
This might also suggest we want to have a delay before automatically
branching so EPEL SIG / Wranglers have time to adjust that package.cfg
after testing the next EL beta.
> There are several changes we can make to both streamline the
> and not increase the maintenance burden on the (other) maintainers
> these packages:
> * Have an EPEL SIG modeled after the SIGs centered around
> language stacks (e.g. Python, Haskell, Java)
> * Have an expedited flow where this SIG can request EPEL branches
> admin access to packages if there are no response from package
> maintainers for a set period (3 days? 1 week?)
Both of those are really short... I guess a week or two might be ok.
1-2 weeks is probably fine, yes, esp. as over time the need for such
manual requests should go down.
> * whether it should be full admin access or whether such
> should be scoped to epel* branches can be discussed. Full admin
> make it possible to adjust the spec in Rawhide to be more EPEL
> friendly, for example
> * Members of the EPEL SIG can then branch these packages early when
> next EL release is branched
> * The member of the SIG doing the branching should be designated as
> primary EPEL assignee for that package
How would that be designated?
Hmm. So right now (correct me if I'm wrong), it seems that only the
main admin for a package can override the bugzilla assignee?
I'm not sure about how this part would work yet. If at the beginning we
try this out with manual infra ticket, I could imagine the EPEL SIG
member that requests EPEL-SIG comaintainership for a package should ask
the main admin to make them the EPEL assignee, or if it goes through an
infra ticket, ask for infra to make that change?
> One deviation we might want to have from how Python SIG works
> probably don't want to encourage packagers to add this EPEL SIG as
> comaintainer preemptively, but only as needed.
That would defeat the purpose of using epel-sig packages as 'always
branch' wouldn't it?
Right - I wasn't thinking of the 'always branch' case (once EPEL-SIG
has commit access requesting a new branch is not a significant delay
anyway). So 'branch for next' in package.cfg might be a better solution
How much tooling change would we need to get collaborators the ability
to request branches if the branch name matches their whitelist,
The other hazard if that different maintainers have different
and epel-sig folks would need to adjust to those. ie, some people
master to have epel conditionals and merge back to epel branches,
don't want that at all. I wonder if it wouldn't make sense to have
way to indicate to people what workflow is in effect for the package
guess spec file comments?)
Maybe spec file comments as well as only granting collaborator
(whitelisting epel* branches) instead of commit / admin access if they
don't want EPEL conditionals?
Michel Alexandre Salim
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2