On 18 February 2016 at 16:37, Dave Johansen <davejohansen(a)gmail.com> wrote:
On Thu, Feb 18, 2016 at 3:54 PM, Bryan J Smith
<b.j.smith(a)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
--
Stephen J Smoogen.