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 [email protected] - http://linkedin.com/in/bjsmith On Feb 18, 2016 18:37, "Dave Johansen" <[email protected]> wrote: > On Thu, Feb 18, 2016 at 3:54 PM, Bryan J Smith <[email protected]> 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 > [email protected] > > http://lists.fedoraproject.org/admin/lists/[email protected] > >
_______________________________________________ epel-devel mailing list [email protected] http://lists.fedoraproject.org/admin/lists/[email protected]
