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 - Technology Mercenary
b.j.smith@ieee.org - http://linkedin.com/in/bjsmith
   

On Feb 18, 2016 18: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.
 
> For most packages, leaving the version that's there alone is probably
> a decent solution, but for packages where security fixes continue to
> happen and are important, then an "official" upgrade path would be
> good. Maybe something like:
> 1) Current maintainer identifies upgraded version and reason for update
> (hopefully limited to security fixes or something along those lines and not
> just "I want a newer version"),
> 2) Notifies intention on mailing list,
> 3) Feedback from community, and
> 4) Perform upgrade

Which works out very well for something that rebases every 2-3 years
... like [RH]SCL.

Again, I wasn't trying to say "be like [RH]SCL," but more like,
"Here's a Red Hat add-on that kinda already has this 'lifecycle' that
Red Hat customers would understand."

Sorry, what I was trying to get across was the idea of having a process that discouraged but allowed for upgrades in a controlled manner while giving users plenty of time to prepare for it.

_______________________________________________
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org