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
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
