On Mon, Sep 14, 2020 at 09:42:36AM -0700, Michel Alexandre Salim wrote:
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
experience.
Yeah, I agree, not everything will want to auto branch... and in fact
this will change from time to time as new versions come out, things are
retired, etc.
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.
I don't like that idea... I've heard many many complaints from people
about package.cfg files and them messing up merges.
I would think at the pagure/src.fp.o level might be better... or if not,
then just a simple 'alwaysepelbranch' file or something thats ignored
except for this use.
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.
Sure, should be a deliberate process.
....snip....
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?
yeah, I think thats indeed the case.
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?
I suppose. I am not keen on adding more infrastructure tickets.
If we can do a workflow that consolidates requests/can be automated that
would be much better IMHO.
> > One deviation we might want to have from how Python SIG
works is...
> > we
> > probably don't want to encourage packagers to add this EPEL SIG as
> > a
> > 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
all around.
How much tooling change would we need to get collaborators the ability
to request branches if the branch name matches their whitelist,
incidentally?
Not sure. Thats a question for Pingou. :)
> The other hazard if that different maintainers have different
> workflows
> and epel-sig folks would need to adjust to those. ie, some people
> want
> master to have epel conditionals and merge back to epel branches,
> some
> don't want that at all. I wonder if it wouldn't make sense to have
> some
> way to indicate to people what workflow is in effect for the package
> (I
> 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?
yeah.
kevin