On 4 April 2016 at 19:13, Stephen John Smoogen <[email protected]> wrote:
> On 4 April 2016 at 10:47, James Hogarth <[email protected]> wrote: > > HI all, > > > How do others feel and does the Steering Committee feel it might be time > to > > revisit the SCL question? > > > > There are 2 issues which still have to be dealt with. > > 1) The upstream Fedora maintainers are not keen on SCL's. We could say > 'yay' SCLs but if the packaging guidelines etc don't allow for SCL's > [and they don't seem to > https://fedoraproject.org/wiki/SoftwareCollections ] we aren't getting > them approved into EPEL because the guidelines used to review packages > don't allow or cover them. > > I read through all the relevant tickets discussing this over the past 3 years last night and the issue primarily seems to be FPC concerned with packaging in Fedora but of course EPEL doesn't really play any consideration in that and the reasons for it are very different. This is the kind of situation I'd expect the EPEL Steering Committee to at least have some view so that EPEL doesn't become irrelevant for many things over the EL7 lifetime. If the issue is indeed FPC then perhaps some EPEL maintainers, and/or the EPEL Steering Committee, ought to make the EPEL implications clear there and seek some EPEL only guidelines with no precedence or implication on Fedora itself. > 2) Packages don't just magically appear. You need to have maintainers > who will keep up the packages. One of the problems that the SCL group > has been having is that the packages are mostly 'good enough for me' > level where the person packages it up and then doesn't want to do any > further maintenance on it. > > I'm a maintainer. I'd love to have my stuff that is either 1) difficult 2) impossible or 3) lesser quality have the obstacles removed to give the same quality experience on EPEL that is seen on Fedora. Reading through the tickets it would appear that maintainers of the relevant technologies (including RH employees in the RHSCL team) would love to get things in, but the requirement to go through a full package review, rather than split out a new branch, when we have such a long tail of reviews that sit dead would be too onerous. And frankly until the okay is given, acceptable guidelines in place and the infrastructure to build and deliver the packages then packages cannot appear - short of magically defying expectation. We trust our packagers on the main branches, we should trust our packagers on their SCL branches (assuming that route is taken which appears sane). > Yes both of these are solvable. We aren't going to solve them soon. > > It's been 3+ years of debates ... this is quite a pessimistic and if really true sad view on things. On 4 April 2016 at 19:22, Kevin Fenzi <[email protected]> wrote: > On Mon, 4 Apr 2016 17:47:25 +0100 > James Hogarth <[email protected]> wrote: > > ...snip... > > > How do others feel and does the Steering Committee feel it might be > > time to revisit the SCL question? > > I'm against using SCL in epel until there are approved Fedora > guidelines. > > That's fine in and of itself and a great ideological stance to take but the reasons and requirements for EPEL differ from Fedora. MattDM on the tickets discussed how some have expressed to him how they would like it to stay on ruby196 (for instance) when Fedora main is on 2.2.4 but for the EL case the reverse is true - wanting newer tech on the older base. The implications for EPEL are somewhat different as well. Whilst Fedora stays current and thus has no trouble with increasing requirements from upstream projects EL is a static entity without SCL. Red Hat directs its users to make use of RHSCL whenever a query is made about a newer compiler, php, python, ruby, mysql, httpd and so on. Technology is also accelerating in development - the world today is very different from 10 even 5 years ago. Can you really blame upstream projects for not wanting to support EOL technologies such as php53 (and officially upstream php54 now) preferring users move on to something supported upstream when they hit a bug in it? EL7 will be around for 8 years yet. I can't see a world even within 2 years where packaging for EPEL on many things is possible anymore. Given that they didn't rebase php in EL6 but instead developed RHSCL and directed people to it when they needed php54+ it doesn't seem likely to see a rebase in EL7 either. With Red Hat's requirement on RHSCL for many things now EPEL should surely have to follow to support its mission statement of: "Make high quality packages that have been developed, tested, and improved in Fedora available for RHEL and compatible derivatives such as CentOS and Scientific Linux." The FPC folks know what they are doing and can figure out all the > corner cases before we would hit them. Last I heard things were > actually pretty close to passing, but then the people driving it just > gave up or moved on to something else. > > I don't blame them for giving up after a 2-3 year debate seemingly going pretty much nowhere having read through the relevant tickets ... > So, it would take some folks willing to push for guidelines, answer > questions, adjust SCLs, etc and get them approved by FPC. > > > The thing is the FPC, understandably, looks out for Fedora first and foremost and due to the general nature of the relationship between Fedora and RHEL this mostly works (with the list of grandfathered exceptions EL gets depending on the date it was branched). With the current project direction of Modularity and the layered container stuff something like SCL (if not specifically SCL) is pretty much inevitable it seems. But the issue there is that is not what Red Hat are using today and thus what EPEL would need to be compatible with. Whatever route is chosen in this area it should facilitate integration with RHSCL to be compatible with RHEL (and CentOS would presumably adapt their SCL SIG accordingly if a common set of provides couldn't be agreed on). If it's not then EPEL gets sidelined. So yes it it'll take time but can EPEL really exist as it is - base only - for the duration of EL7 and still achieve it's goal, and what impact would missing this have on our users and the reputation of EPEL as the best extension to a RHEL based system?
_______________________________________________ epel-devel mailing list [email protected] http://lists.fedoraproject.org/admin/lists/[email protected]
