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

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

 



On Mon, 2020-09-14 at 08:54 -0700, Kevin Fenzi wrote:
...snip...
> I'll add that in addtion to some maintainers not wanting to maintain
> 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
> or
> whatever would make more sense and the package set may well not be
> the
> same. 
> 
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 my
> package
> branched for the next epel as soon as it's available"? I suppose in
> part
> 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
experience.

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
> > process,
> > and not increase the maintenance burden on the (other) maintainers
> > of
> > these packages:
> > 
> > * Have an EPEL SIG modeled after the SIGs centered around
> > programming
> > language stacks (e.g. Python, Haskell, Java)
> > * Have an expedited flow where this SIG can request EPEL branches
> > and
> > 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 access
> > should be scoped to epel* branches can be discussed. Full admin
> > would
> > 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
> > the
> > next EL release is branched
> > * The member of the SIG doing the branching should be designated as
> > the
> > 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 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?

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

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/michel@xxxxxxxxxxxxxxx
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
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