On Thu, Feb 18, 2016 at 5:22 PM, Stephen John Smoogen <smo...@gmail.com> wrote:
> On 18 February 2016 at 16:37, Dave Johansen <davejohan...@gmail.com> > wrote: > > On Thu, Feb 18, 2016 at 3:54 PM, Bryan J Smith <b.j.sm...@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.
_______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
