On 18 February 2016 at 12:46, Kevin Fenzi <ke...@scrye.com> wrote: > On Tue, 16 Feb 2016 21:42:18 -0700 > Stephen John Smoogen <smo...@gmail.com> wrote: > >> ======================== >> Apologies and So Forth >> ======================== >> >> >> First, I would like to apologize for the delay in getting this post >> done. I really didn't realize the amount of energy the trip would take >> from me and how fuzzy brained I was for a week afterwords. Second, I >> would like to thank the Open Source and Standards (OSAS) group at Red >> Hat for sponsoring me that week. I believe I got a lot of things done >> and that we can work on getting Extra Packages for Enterprise Linux >> (EPEL) moving forward in some direction. Third I would like to thank >> everyone who took the time to talk to me at one of these places to >> tell me about what they were able to do with EPEL and what they were >> no longer able to use it for. > > Thanks for talking to folks and writing this up! > > ...snip... > >> * The packaging guidelines for each EPEL version are not clear. This >> is mainly due to the fact that they are usually based off of older >> versions of Fedora (Fedora-6 for EPEL-5, Fedora-12 for EPEL-6, and >> Fedora-18 for EPEL-7) that may conflict with each other or with how >> things are being done in current EPEL. > > I've always gone with: "Fedora guidelines apply except for these small > changes", but yeah, we could be better about those changes. Tibb's > recent macro works might reduce these, but I don't think we can ever > get to 0. >
One of the requests was to have snapshots of the guidelines that we worked each channel against so that it was clearer what 5 wanted versus 6 wanted. >> * EPEL does not have a regular release structure like Fedora and RHEL >> have. There isn't an EPEL-5.11 channel with an epel-updates-5.11 >> where updates are available. Because of various repository >> limitations, this means that directories aren't able to keep >> multiple old copies so downgrades when things do break aren't easy. > > Yeah. I think we could include 2 versions of everything (at the cost of > 2x of the mirror space and bandwith), but then you have things like > foo-1.0 has a major security bug and foo-1.1 came out to fix it, and > you trick someone into downgrading or installing the old one and > exploit them. ;( > If we don't delete them from koji we aren't fixing anything because if I can trick you to downgrade, I can trick you to go to the version in koji because it has the fix needed. [Since I have seen people talk about their systems getting broken into after they did exactly that.. I think it isn't going too far in assumptions :)] >> * EPEL promises to keep things stable and only update for fixes, but >> this is only done on a few packages where others get upgraded to and >> fro. There does not seem to be much "steering" or "release >> engineering" of what is in the trees. > > Yeah, I think mostly this is due to the fact that there is not anyone > who works on EPEL full time. Everyone who does things does them in > their "spare" time, so having some kind of micro scrutiny isn't in the > cards. ;( > > I think we could improve this with more feedback... when an > incompatible upgrade goes out, ask people to note it so we can talk to > the maintainer and ask them not to do that kind of thing. > Or not promise it at all. I think the underlying issue is that people think we do have full-time people working on EPEL with the same controls (if not more) than we have in Fedora. >> * EPEL only covers part of Enterprise Linux (the Server product) but a >> lot of packages are for the Workstation but there is no way to see >> when things replace/conflict with them. [People believe that we >> build against the equivalent of CentOS-5/6/7 versus a subchannel.] > > Yeah, not sure how to fix that without a second workstation branch. :( The only monstrosities I have thought of were: epel-server-N epel-workstation-N epel-combined-N which sounded like a ton of work for little benefit. > >> * EPEL sometimes has weird breaks between releases. The git in EPEL-5 >> is newer than what is in EL-6 in a way that was breaking >> repositories when pushes were done from EL-5 systems. [People >> believe there is a promise that such changes are tested against.] > > Huh, first I have heard of that one.. Me too. It took up half the short meeting because it broke CERN and a couple other places. >> I don't think anything above is new to people who have been >> contributing to EPEL in the last ~10 years. A lot of the problems are >> ones that were brought up in the beginning as we tried to square the >> circle of differing use cases. However, I wanted to catalogue them >> here and then make a promise that I will do my best to figure out ways >> to solve them by FOSDEM 2017 in some form or another. > > It sounds to me a lot of it is communication. Perhaps we could figure > out some way to more directly communicate with users. > OH yeah.. that was one of the items.. why is the website so old and dead. I told them your story about trying to fix it up and finding parts reverted over and over again. Someone recommended : Just start from scratch and kill the old stuff. Which I think was part of the "recharter" talks. > 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
