On Thu, Feb 18, 2016 at 5:22 PM, Stephen John Smoogen <smooge@gmail.com> wrote:
On 18 February 2016 at 16:37, Dave Johansen <davejohansen@gmail.com> wrote:
> On Thu, Feb 18, 2016 at 3:54 PM, Bryan J Smith <b.j.smith@ieee.org> 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 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+ years, for 6-7
>> years total of the RHEL release.
>>
>> The idea here is that you have up to three (3) years to "rebase."  ;)
>>
>> Not that [RH]SCL is 3 years and that's it.  I mean ... understand my
>> intent here.  Sustaining engineering is _not_ free, it's _not_
>> upstream, and people should be expected to rebase every 2-3 years,
>> when it comes closer to Upstream.
>>
>> Again, understand the "bigger picture" of my "suggestion."
>>
>> > For example, we just barely started upgrading to EL 7 ... (cut)
>>
>> _So_ you will likely be on the _second_ [RH]SCL release for RHEL 7,
>> instead of the _first_.  So ... what's the problem?
>>
>> So ... I have to now ask ... have you used [RH]SCL?  ;)
>>
>> I.e., Again, it's _not_ only 3 years of RHEL, but 3 years per release,
>> with each RHEL releases getting 2-3 releases over 6-7 years.
>>
>> Ergo ...
>
>
> SCL is an AWESOME idea, but for our organization, having to jump to the next
> version of an SCL every 2-3 years just isn't possible. We use RHEL because
> of its long support life cycle and starting to use the SCL breaks that idea.
> If SCL had a lifecycle more akin to RHEL (i.e. something like release half
> as often and support for twice as long), then it would be a different story.
>

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
someone else. The work to try and keep software 'stable' over a 6
month lifetime seems to grow exponentially so that by the end of the 3
years it is 1000 times harder than it was in the beginning. Now the
number of people who are wanting to work on this older software for
free (or if they are doing it for themselves to share it for "free")
is incredibly small. I expect that we are looking at 10 packages in
EPEL maybe? So we are going to be looking at rebasing and updates
every 2-3 years no matter what for the majority of software. Expecting
it not to be like that is Cnut's tidal problem.


https://en.wikipedia.org/wiki/King_Canute_and_the_waves

As mentioned several times already, EPEL means different things to different people. To me stability is significantly more important than having the latest and greatest, so for a fair number of packages that means "just leave things alone" and the "waves" are self inflicted.

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 "discourages but allows updates" with a very deliberate and controlled process is the right model for EPEL.