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

2020-10-11 Thread Christoph Karl
Hello Alexandre! On 11.09.20 20:52, Michel Alexandre Salim wrote: The rationale is that many Fedora packagers do not specifically care about EL, and with their long release cycles the maintenance burden is higher (e.g. upgrading to fix a security vulnerability might not be possible if the newer

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

2020-09-15 Thread Kevin Fenzi
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

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

2020-09-15 Thread Kevin Fenzi
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

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

2020-09-14 Thread Michel Alexandre Salim
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.

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

2020-09-14 Thread Kevin Fenzi
On Fri, Sep 11, 2020 at 11:52:03AM -0700, Michel Alexandre Salim wrote: ...snip... > > EPEL packages are maintained in dist-git as additional branches on > Fedora packages; however, unlike with Fedora releases, where by default > a package gets branched for any new Fedora release, EPEL branches

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

2020-09-13 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Sep 11, 2020 at 03:50:58PM -0700, Michel Alexandre Salim wrote: > We discussed the proposal a bit at today's EPEL SC meeting; here's a > revised proposal taking into account the suggestions from the meeting > and earlier in this list. > > ## The SIG > - bstinson pointed out that

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

2020-09-11 Thread Michel Alexandre Salim
We discussed the proposal a bit at today's EPEL SC meeting; here's a revised proposal taking into account the suggestions from the meeting and earlier in this list. ## The SIG - bstinson pointed out that epel-wranglers was started to address the same issue, we can resurrect that - we want to

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

2020-09-11 Thread Michel Alexandre Salim
We discussed the proposal a bit at today's EPEL SC meeting; here's a revised proposal taking into account the suggestions from the meeting and earlier in this list. ## The SIG - bstinson pointed out that epel-wranglers was started to address the same issue, we can resurrect that - we want to

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

2020-09-11 Thread Michel Alexandre Salim
On Fri, 2020-09-11 at 15:44 -0400, Neal Gompa wrote: > On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood > wrote: > > Michel Alexandre Salim writes: > > > > > * Have an expedited flow where this SIG can request EPEL branches > > > and > > > admin access to packages if there are no response from

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

2020-09-11 Thread Neal Gompa
On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood wrote: > > Michel Alexandre Salim writes: > > > * 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?) > > *

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

2020-09-11 Thread Troy Dawson
On Fri, Sep 11, 2020 at 12:10 PM Robbie Harwood wrote: > > Michel Alexandre Salim writes: > > > * 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?) > > *