On Tue, 7 Jan 2020 at 10:48, Young, Gregory gregory.young@solarwinds.com wrote:
My personal feeling is there have been very high barriers to contributing to CentOS.
- For the love of all that is pink and fluffy, we need to update the versions of third party packages we ship. If RHEL won't, CentOS should. For instance, we still ship Jetty 9.2, which is EOL and not receiving security updates. 9.3 is also EOL. 9.4 is quite stable at this point (as they are about to go beta on 10.0), so we should be shipping 9.4. PostgreSQL is another example. We ship 9.2. 12.1 is the current release, and the appliance I work on is shipping 10.11 as it's stable version. 9.2 is so far out of EOL... it has been superseded by 9.3, 9.4, 9.5, 9.6, 10, 11 and 12. If you want an example of what we should be shipping as the stable versions, cPanel is a very good example. They run on CentOS, but sooooooo many packages have to be built by them to make their servers secure.
The true purpose of an enterprise software is to make sure that a site can run crufty old software which depends on some version of a library no longer supported by upstream beyond simple bug fixes. [I can say from experience that updating jetty will break all kinds of commercial payroll apps which expect X version]. In the end, enterprise software upgrades at the rate of whatever the majority of accounting systems need to make payroll and tax filings happen. And then you find out that even if you move to the cloud, you still have to keep the old records active for 10+ years for all kinds of reasons.
Enterprise Operating Systems are the semi trucks of distributions.
They are slow, lumbering, noisy but carry a lot of stuff from point A to point B. Other operating systems are like smaller trucks or cars or even gulf-carts.. they each have their place and reasons for moving at the speeds they are for. The issue is to not try and expect a Bugatti to haul a 40 ton trailer or a Peterbilt to outlap a Lamborghini [you can do both with a lot of work, but there is little practicality of said work.] And I would not want either one of them on a golf course unless I was expecting to returf the entire area.
I'm not against retaining older streams of the software. Jetty 9.2 can stay for legacy reasons (although in 2020 I would not recommend running it, especially in systems that handle finances/payroll/taxes/PCI compliance tasks). Having different jetty packages where the package name is i.e. "jetty-9.4", "jetty-9.3", etc. and properly configuring the RPM SPEC conflicts can avoid 2 jetty versions being installed on the same system, with the same folder config. If you want to install a parallel, different version of Jetty, that would be something you have to do manually (as you also will need to change the default port bindings, folders, library, web root, etc.). If we do so though, we should set a more current, stable version as the default (aka in the jetty 9.4 SPEC set an alias of "jetty" so if someone types "yum -y install jetty" they get 9.4). A similar thing is currently done with OpenJDK and the various 7, 8, 9 versions. As for the dependencies, the .SPEC file has you covered as well. There is a Requires field and you can set version numbers on the dependencies as well (Requires: java >= 1:1.8.0, somelib < 1.2.1). Yes, we will need to also maintain those older dependencies in the RPM Repos.
As the OS guy for a major appliance, and as a former tech in both the datacenter and MSP fields, I can advise you in a lot of cases people and companies will put off upgrades as long as they can (Heck we still have customers using RHEL/CentOS 5, Windows XP and Server 2003, even though we dropped support for them 4 years ago), until it reaches a point where they are forced to upgrade. Maybe not right now in 8, but in streams we should be moving towards the more modern, stable versions of third-party packages, even if it means we need to also provide separate older packages as well (like jetty 9.3). At some point down the road, either on a point release, or the next major release, we should announce deprecation of the older versions (well in advance so enterprises have time to plan the upgrades) and remove them from production.