On 18 February 2016 at 12:46, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Tue, 16 Feb 2016 21:42:18 -0700
Stephen John Smoogen <smooge(a)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(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject...
--
Stephen J Smoogen.