On 18 February 2016 at 12:56, Kevin Fenzi <ke...@scrye.com> wrote: > >> 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. >
Sorry what I meant that it is built against all of RHEL not just a couple of channels. Again this isn't a promise we ever made, but one people assume we have made (and get surprised when they find out differently). >> ============= >> 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" > And this is where I made things worse by conflicting with channels versus "entire OS" >> 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. Well this was more of a rule. The exact procedures of how this is done would be in a separate document so that it can be changed easily. > >> 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. > Probably but I would prefer to either have them one way or another :). I would prefer not to have the "where is my N?" during the decay days of EPEL-6 that we are seeing in EL-5 as packages get EOL'd that people expected to be there. >> 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? > Well that is another promise some people think we make. They thought we waited until CentOS came out before the buildroots were changed but that isn't something I think we have ever done. I forgot to put that in. Part of this comes in with the procedures to be put in place. If it is too hard to deal with alt-arch it would be clearer that we said "We only support and build packages against the base RHEL release." Then we can rule out the window between rhel and centos.. and the altarch can come up with their own solution. If we do want to have the alt-arch it comes into a bigger issue depending on how the alt-arch is implemented in EPEL. There seem to be multiple ways to do this that need information from Release Engineering to solve. > A good start anyhow, thanks smooge. > > kevin > > _______________________________________________ > epel-devel mailing list > epel-devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org > -- Stephen J Smoogen. _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
