On Tue, 16 Feb 2016 23:24:58 -0700 Stephen John Smoogen <[email protected]> wrote:
...snip... > However during that time there have been many > rules which it has tried to keep: > > 1. Do not do disruptive upgrades. Try to backport security fixes or do > upgrades which do not change API/ABI issues. > 2. Be prepared to support the same package for the life of an > Enterprise Linux release. > 3. Never replace or conflict with packages in the base Enterprise > Linux. > 4. They should never require manual updates or changes between > updates. 5. Follow Fedora rules for bundling, licensing, and similar > things. > > There are some promises some people feel like we have made also: > > 1. Packages will never disappear. [They don't disappear from Fedora 12 > even if it is archived.. ] To my understanding we never made this promise. We should try and communicate why it's NOT something we promise. > 2. Packages will work from EL-X.0 to EL-X.N. [EPEL will rebuild > packages regularly to deal with any ABI items] Well, not regularly, but when there is a problem. With one of the recent 7.x releases there were a number of packages that needed rebuild. We didn't do a very nice job of it, but in the end we collected the bugs, rebuilt all those things and pushed the updates out. It would definitely be better to automate that and find these asap instead of after the fact with bugs. > 3. Packages are built against all of an Enterprise Linux 'base' (EG > whatever is in CentOS/Scientific Linux base). I thought we were always clear that we built against RHEL. But perhaps not. > > In many cases those promises aren't kept now or when they are > attempted to be kept are impossible to do. > > * Most software which uses a database back end requires schema updates > ranging from dump/reload to long running change processes. > * A lot of software rebases itself internally to the point that trying > to backport a security fix usually requires a lot of coding skill in > the package. > * The Enterprise Linux lifetime has increased from 5 years to 10 years > since EPEL started. While people were interested in supporting a > package for 3-4 years.. doing so for 10 years is too much for a > volunteer position. > * The Enterprise Linux is not the same as it was in EL-3/4/5 where > software versions were rarely 'rebased' to a newer release. Instead > software would be recoded to work in the older software as much as > possible. Currently in EL-7, the desktop and other parts of the OS > were greatly updated between 7.1 and 7.2 with the idea that this > will be the norm for all releases in order to keep the product > relevant to the majority of users. > > From the above, 3 of the 5 promises are either too much to keep or > haven't been kept in a long time. Yeah, those I all agree with. > ============= > What to Do? > ============= > > Because we haven't been able to keep many promises, but feel like we > should there seem to be a couple of options ahead: > 1. Ignore and do nothing. I don't like the status-quo but I think it > needs to be listed as something that can happen. > 2. Try to keep the original charter and be a lot more picky about what > is in EPEL so that we can meet those promises. > 3. Figure out what we can do, and go to the appropriate Fedora body to > recharter ourselves to meet those more reasonable goals. > > Now number 3 may seem to be busy work, but I have found for the > conservative minded enterprise maintainer, it is very hard to give up > doing something even if you are failing until you are told you can > stop trying. It also makes it clearer to future people working on EPEL > in 2024 what they are trying to solve and how to change when the world > of 2024 needs different solutions. I'm really not sure talking to another fedora body is needed. I really suspect if we came up with a new charter and all (all the people doing work on EPEL) agreed to it, we could just do it. FESCo or the council is likely to just say "sure, thats fine, do whatever". But we could do so if everyone wants... > ============================= > What would be in my charter > ============================= > > > 1. EPEL is run by the EPEL Steering Committee. They act as > sub-equivalents to the Fedora Extras Steering Committee, Fedora > Packaging Committee and Fedora Release Engineering. (No extras anymore. ;) > 2. Packages in EPEL will never replace or conflict with packages in > the base Enterprise Linux. What does that mean? If we want it to be what we have now: "Packages in EPEL will never replace or conflict with packages in the RHEL channels we build EPEL against. Adding or removing channels is done by the steering committee" > 3. Packages in EPEL will follow Fedora rules for bundling, licensing, > and similar things. Exceptions to this will exist and will be > documented in appropriate place. > 4. EPEL release engineering can set up systems to rebase packages in > regular intervals. [There are multiple ways of doing this that I > will try to outline in other proposals this week.] Yeah, 'regular' is a bit too wishy washy. > 5. The only promise of a lifetime of a package is between dot releases > of the Enterprise Linux. Maintainers should make an honest effort > to support a package for the "life" of a sub-release (6.8->6.9) but > no longer. > 6. Packages in a dot release will not disappear during that > time. There is no promise after that time. [If EPSco approves of a > method that packages are regularly archived, then users can use > that as a simpler method to get old packages.] I think these might be the most controversial bits. > 7. EPEL only supports the current dot release. If a package in > EL-6.now works on 6.0.z that is great. If it doesn't, it is up to > the user (and not the maintainer or EPEL) to deal with it. [Again > if an archive method is setup, then those older versions would just > be in something like /pub/archives/epel/epel-6.8/ or some similar > setup] Yeah, I think we have always said we only support the current release, but good to spell it out. > Those are my starting points for a rechartered EPEL. Please join in > the discussion on the EPEL-devel mailing list. I think we need to consider the window between rhel release and centos release. Do we wait? Do we not wait? do we test? A good start anyhow, thanks smooge. kevin
pgpnlB2QIbkBA.pgp
Description: OpenPGP digital signature
_______________________________________________ epel-devel mailing list [email protected] http://lists.fedoraproject.org/admin/lists/[email protected]
