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
On Mon, Sep 14, 2020 at 08:54:57AM -0700, Kevin Fenzi wrote:
> On Fri, Sep 11, 2020 at 11:52:03AM -0700, Michel Alexandre Salim wrote:
> > There are several changes we can make to both streamline the process,
> > and not increase the maintenance burden on the (other) maintainers of
> > these packa
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,
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 ar
Dne 14. 09. 20 v 15:01 Vít Ondruch napsal(a):
> Dne 14. 09. 20 v 12:03 Pierre-Yves Chibon napsal(a):
>> On Mon, Sep 14, 2020 at 10:35:18AM +0200, Vít Ondruch wrote:
>>> Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a):
On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote:
>
Dne 14. 09. 20 v 12:03 Pierre-Yves Chibon napsal(a):
> On Mon, Sep 14, 2020 at 10:35:18AM +0200, Vít Ondruch wrote:
>> Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a):
>>> On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote:
Reading this proposal and with the EPEL8 experi
On 14. 09. 20 12:03, Pierre-Yves Chibon wrote:
You're speaking about the bugzilla overrides, that in practice are entirely
separated from granting access to the epel* branches to someone.
If you go on the project's settings, click to add an user or group, you'll see
the "collaborator" access leve
On Mon, Sep 14, 2020 at 10:35:18AM +0200, Vít Ondruch wrote:
>
> Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a):
> > On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote:
> >> Reading this proposal and with the EPEL8 experience, where there was not
> >> even wiki page, where I
On Mon, Sep 14, 2020, 10:35 Vít Ondruch wrote:
>
> Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a):
> > On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote:
> >> Reading this proposal and with the EPEL8 experience, where there was not
> >> even wiki page, where I could state
Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a):
> On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote:
>> Reading this proposal and with the EPEL8 experience, where there was not
>> even wiki page, where I could state that I don't care about EPEL and I
>> had to reply into ev
On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote:
> Reading this proposal and with the EPEL8 experience, where there was not
> even wiki page, where I could state that I don't care about EPEL and I
> had to reply into every BZ independently, wouldn't it make sense to move
> EPEL into its
Reading this proposal and with the EPEL8 experience, where there was not
even wiki page, where I could state that I don't care about EPEL and I
had to reply into every BZ independently, wouldn't it make sense to move
EPEL into its own dist-git namespace?
I guess that in the CVS days, having EPEL b
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-wrang
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 limit
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 pac
Neal Gompa writes:
> 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
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?)
> > * whethe
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?)
> > * wheth
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?)
> * whether it should be full admin access or whether such access
> should be
Hello all,
Following up from last week's EPEL Steering Committee meeting, I'm
presenting a proposal to create a dedicated SIG to make it easier to
get Fedora packages into EPEL and keep them maintained.
Using the Fedora Changes Process template for this to help structure
the proposal, though this
20 matches
Mail list logo
