[EPEL-devel] Re: EPEL Proposal #1: Rechartering

2016-02-27 Thread Bryan J Smith
Q: Do you understand the purpose of RHSCL PR EPEL? ;) You want RHEL, but neither RHSCL nor EPEL is it, nor designed to be it. That's why I said ... EPEL's ideal aimpoint, when feasible, should be like RHSCL. ;) -- bjs DISCLAIMER: Sent from phone, please excuse any typos -- Bryan J Smith -

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

2016-02-27 Thread Ken Dreyer
On Fri, Feb 26, 2016 at 2:38 PM, Felix Schwarz wrote: > Also as a sysadmin I dislike that stuff in EPEL can change at any time > (whenever the maintainer can not support the old version anymore). If EPEL had > some kind of "release" (e.g. tied to RHEL point releases)

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

2016-02-26 Thread Felix Schwarz
Am 19.02.2016 um 16:53 schrieb Dave Johansen: > But as was also mentioned, a lot of packages have jumped on the Chrome > bandwagon with crazy release cycles and maintaining security fixes in those > cases is basically impossible for a volunteer effort. From my perspective, > having a policy that

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

2016-02-19 Thread Dave Johansen
On Thu, Feb 18, 2016 at 5:22 PM, Stephen John Smoogen wrote: > On 18 February 2016 at 16:37, Dave Johansen > wrote: > > On Thu, Feb 18, 2016 at 3:54 PM, Bryan J Smith > wrote: > >> > >> Dave Johansen wrote: > >> > RHSCL is a

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

2016-02-19 Thread Kevin Fenzi
On Thu, 18 Feb 2016 17:22:07 -0700 Stephen John Smoogen wrote: > One of the issues that I am finding is that most software these days > has only a 3 year lifetime at best.. if you want it to be longer you > are going to pay for it either by maintaining it yourself or paying >

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

2016-02-18 Thread Joe Julian
On February 18, 2016 7:08:34 PM PST, Michael Stahnke wrote: >I was trying to reply to everything inline, but being the responsible >posters ya'll are, you trimmed and everything leaving context harder to >just jump in on :) > >Way back in the day when I had a lot more

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

2016-02-18 Thread Stephen John Smoogen
On 18 February 2016 at 16:37, Dave Johansen wrote: > On Thu, Feb 18, 2016 at 3:54 PM, Bryan J Smith wrote: >> >> Dave Johansen wrote: >> > RHSCL is a non-starter where I work (and I imagine at other >> > locations). 2-3 years of support just isn't

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

2016-02-18 Thread Bryan J Smith
Dave Johansen wrote: > RHSCL is a non-starter where I work (and I imagine at other > locations). 2-3 years of support just isn't enough to make it a > worthwhile investment. Well, there usually _is_ more than one (1) [RH]SCL per RHEL release. So it's more like 2-3 releases that "rebase" every 2+

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

2016-02-18 Thread Dave Johansen
On Thu, Feb 18, 2016 at 2:39 PM, Bryan J Smith wrote: > Stephen John Smoogen wrote: > > Sorry what I meant that it is built against all of RHEL not just a > > couple of channels. Again this isn't a promise we ever made, but one > > people assume we have made (and get

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

2016-02-18 Thread Bryan J Smith
Stephen John Smoogen wrote: > Sorry what I meant that it is built against all of RHEL not just a > couple of channels. Again this isn't a promise we ever made, but one > people assume we have made (and get surprised when they find out > differently). I can only imagine how difficult this gets for

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

2016-02-18 Thread Stephen John Smoogen
On 18 February 2016 at 12:56, Kevin Fenzi wrote: > >> 3. Packages are built against all of an Enterprise Linux 'base' (EG >>whatever is in CentOS/Scientific Linux base). > > I thought we were always clear that we built against RHEL. > But perhaps not. > Sorry what I meant

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

2016-02-18 Thread Kevin Fenzi
On Thu, 18 Feb 2016 12:11:28 -0800 Joe Julian wrote: > On February 18, 2016 11:56:54 AM PST, Kevin Fenzi > wrote: > >On Tue, 16 Feb 2016 23:24:58 -0700 > >Stephen John Smoogen wrote: > > > >...snip... > > > >> 2. Packages in EPEL will

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

2016-02-18 Thread Kevin Fenzi
On Tue, 16 Feb 2016 23:24:58 -0700 Stephen John Smoogen wrote: ...snip... > However during that time there have been many > rules which it has tried to keep: > > 1. Do not do disruptive upgrades. Try to backport security fixes or do >upgrades which do not change API/ABI