Re: [EPEL-devel] Re: Proposing an EPEL packaging SIG

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux