To whom it may concern, Okay I¹m currently maintaining the torque package that is currently at an impasse for moving forward. https://bugzilla.redhat.com/show_bug.cgi?id=1328958 (desire from upstream to upgrade to v6.0.1) https://bugzilla.redhat.com/show_bug.cgi?id=1321154 <https://bugzilla.redhat.com/show_bug.cgi?id=1321154>=1321154> (desire to downgrade v4.2.10 to remove numa support and or fork package) https://bugzilla.redhat.com/show_bug.cgi?id=1231148 (desire to have numa support enabled) So as I read the https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies about updates in EPEL the way to close these two bugs is to downgrade the torque package to the version without numa support. The assumption for the user who wants to run torque v6.0.1 is to install Fedora where these versions can change every 18 months and they¹ll get the version and fix they need. For most major parts of the Fedora/RHEL pipeline this works fine, kernel, Xorg, gnome, etc. However, I¹d like to propose an alternative for EPEL since the goal of the software developers is not to target Fedora but RHEL directly. The normal package lifecycle for Fedora/EPEL developers starts when the packager decides to cut a Œstable¹ release of his new code and wants it distributed. We take that code and package it for Fedora, since that¹s what the developer targeted his new release for. The software is more than likely targeted for Fedora as that distribution contains the latest versions of all the OSS out there. The package may experience a branch/fork (whatever you want to call it) to EPEL when a new release of RHEL is created and when the need for it gets expressed. The version of that package in EPEL will remain fixed for several reasons. First is that the dependent packages are usually managed by RedHat and are fixed, so API compatibility issues quickly come into play when updating a package who¹s developers are targeting Fedora as their development environment. Second, is the Guidelines and Polices mentioned in the EPEL Fedora Wiki. People want stability when they are using an OS that¹s managed like a stable OS and we can¹t have instability in EPEL as it looks bad on the RedHat OS which gets really problematicŠ Identifying the gap for the Torque package specifically (and probably others) is that the developers for the package are targeting enterprise Linux distributions for their development environments. Within the HPC community we support scientific codes that are very sensitive to changes in the OS and we have to run enterprise linux distributions on our clusters to make the applications work. Hence, most of the software that is specific to HPC environments is built and developed on RHEL (for our purposes anyway, we don¹t care about those SLES people). This presents a problem, I¹ve got three major versions of Torque that are supported by the developers and all of them were built and developed for RHEL and should be included in EPEL. However, I¹ve only got one spec and one version of Torque I can support for EPEL and its fixed for all time. I would very much like to have a solution that will work for all of my users. I¹d also like to have a solution for users to move forward in major versions of torque when they are ready without having to compromise stability within that major version of torque. Some of the solutions I¹ve thought of are the following: * Have three forks of torque in EPEL; stable, feature and unstable * stable is the cut of torque when that major version of RHEL was released and only changes if there¹s security issues * feature updates from unstable only in very specific situations * minor release of RHEL comes out and that major release hasn¹t gotten into LTS security patches only mode from RedHat. * unstable updates with whatever the upstream has for new code whenever they release it (treated like Fedora Package) If other¹s have this issue and would like to see these their package split like this please feel free to speak up. This seems like a gap that we can fix though it would be nice to know how to move forward with this. If what I¹m suggesting isn¹t possible I¹m perfectly willing to hand over management of the torque package to someone else. Thanks, - David Brown
