[EPEL-devel] Re: EPEL Proposal #1: Rechartering
Q: Do you understand the purpose of RHSCL PR EPEL? ;) You want RHEL, but neither RHSCL nor EPEL is it, nor designed to be it. That's why I said ... EPEL's ideal aimpoint, when feasible, should be like RHSCL. ;) -- bjs DISCLAIMER: Sent from phone, please excuse any typos -- Bryan J Smith - Technology Mercenary b.j.sm...@ieee.org - http://linkedin.com/in/bjsmith On Feb 18, 2016 18:37, "Dave Johansen"wrote: > On Thu, Feb 18, 2016 at 3:54 PM, Bryan J Smith wrote: > >> Dave Johansen wrote: >> > RHSCL is a non-starter where I work (and I imagine at other >> > locations). 2-3 years of support just isn't enough to make it a >> > worthwhile investment. >> >> Well, there usually _is_ more than one (1) [RH]SCL per RHEL release. >> So it's more like 2-3 releases that "rebase" every 2+ years, for 6-7 >> years total of the RHEL release. >> >> The idea here is that you have up to three (3) years to "rebase." ;) >> >> Not that [RH]SCL is 3 years and that's it. I mean ... understand my >> intent here. Sustaining engineering is _not_ free, it's _not_ >> upstream, and people should be expected to rebase every 2-3 years, >> when it comes closer to Upstream. >> >> Again, understand the "bigger picture" of my "suggestion." >> >> > For example, we just barely started upgrading to EL 7 ... (cut) >> >> _So_ you will likely be on the _second_ [RH]SCL release for RHEL 7, >> instead of the _first_. So ... what's the problem? >> >> So ... I have to now ask ... have you used [RH]SCL? ;) >> >> I.e., Again, it's _not_ only 3 years of RHEL, but 3 years per release, >> with each RHEL releases getting 2-3 releases over 6-7 years. >> >> Ergo ... >> > > SCL is an AWESOME idea, but for our organization, having to jump to the > next version of an SCL every 2-3 years just isn't possible. We use RHEL > because of its long support life cycle and starting to use the SCL breaks > that idea. If SCL had a lifecycle more akin to RHEL (i.e. something like > release half as often and support for twice as long), then it would be a > different story. > > >> > For most packages, leaving the version that's there alone is probably >> > a decent solution, but for packages where security fixes continue to >> > happen and are important, then an "official" upgrade path would be >> > good. Maybe something like: >> > 1) Current maintainer identifies upgraded version and reason for update >> > (hopefully limited to security fixes or something along those lines and >> not >> > just "I want a newer version"), >> > 2) Notifies intention on mailing list, >> > 3) Feedback from community, and >> > 4) Perform upgrade >> >> Which works out very well for something that rebases every 2-3 years >> ... like [RH]SCL. >> >> Again, I wasn't trying to say "be like [RH]SCL," but more like, >> "Here's a Red Hat add-on that kinda already has this 'lifecycle' that >> Red Hat customers would understand." >> > > Sorry, what I was trying to get across was the idea of having a process > that discouraged but allowed for upgrades in a controlled manner while > giving users plenty of time to prepare for it. > > ___ > epel-devel mailing list > epel-devel@lists.fedoraproject.org > > http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org > > ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL Proposal #1: Rechartering
On Fri, Feb 26, 2016 at 2:38 PM, Felix Schwarzwrote: > Also as a sysadmin I dislike that stuff in EPEL can change at any time > (whenever the maintainer can not support the old version anymore). If EPEL had > some kind of "release" (e.g. tied to RHEL point releases) I'd like to see > "most" incompatible upgrades happen at that time - with some kind of release > notes where I can read about the changes before. > > Ideally I have some time (e.g. a month or so) to schedule the upgrade and deal > with any fall-out. I'm curious, do you test updates that are going through epel-testing? - Ken ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL Proposal #1: Rechartering
Am 19.02.2016 um 16:53 schrieb Dave Johansen: > But as was also mentioned, a lot of packages have jumped on the Chrome > bandwagon with crazy release cycles and maintaining security fixes in those > cases is basically impossible for a volunteer effort. From my perspective, > having a policy that "discourages but allows updates" with a very deliberate > and controlled process is the right model for EPEL. Sounds good to me. Also as a sysadmin I dislike that stuff in EPEL can change at any time (whenever the maintainer can not support the old version anymore). If EPEL had some kind of "release" (e.g. tied to RHEL point releases) I'd like to see "most" incompatible upgrades happen at that time - with some kind of release notes where I can read about the changes before. Ideally I have some time (e.g. a month or so) to schedule the upgrade and deal with any fall-out. If that's possible with Stephen's rechartering I'm more than happy. Felix ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL Proposal #1: Rechartering
On Thu, Feb 18, 2016 at 5:22 PM, Stephen John Smoogenwrote: > On 18 February 2016 at 16:37, Dave Johansen > wrote: > > On Thu, Feb 18, 2016 at 3:54 PM, Bryan J Smith > wrote: > >> > >> Dave Johansen wrote: > >> > RHSCL is a non-starter where I work (and I imagine at other > >> > locations). 2-3 years of support just isn't enough to make it a > >> > worthwhile investment. > >> > >> Well, there usually _is_ more than one (1) [RH]SCL per RHEL release. > >> So it's more like 2-3 releases that "rebase" every 2+ years, for 6-7 > >> years total of the RHEL release. > >> > >> The idea here is that you have up to three (3) years to "rebase." ;) > >> > >> Not that [RH]SCL is 3 years and that's it. I mean ... understand my > >> intent here. Sustaining engineering is _not_ free, it's _not_ > >> upstream, and people should be expected to rebase every 2-3 years, > >> when it comes closer to Upstream. > >> > >> Again, understand the "bigger picture" of my "suggestion." > >> > >> > For example, we just barely started upgrading to EL 7 ... (cut) > >> > >> _So_ you will likely be on the _second_ [RH]SCL release for RHEL 7, > >> instead of the _first_. So ... what's the problem? > >> > >> So ... I have to now ask ... have you used [RH]SCL? ;) > >> > >> I.e., Again, it's _not_ only 3 years of RHEL, but 3 years per release, > >> with each RHEL releases getting 2-3 releases over 6-7 years. > >> > >> Ergo ... > > > > > > SCL is an AWESOME idea, but for our organization, having to jump to the > next > > version of an SCL every 2-3 years just isn't possible. We use RHEL > because > > of its long support life cycle and starting to use the SCL breaks that > idea. > > If SCL had a lifecycle more akin to RHEL (i.e. something like release > half > > as often and support for twice as long), then it would be a different > story. > > > > One of the issues that I am finding is that most software these days > has only a 3 year lifetime at best.. if you want it to be longer you > are going to pay for it either by maintaining it yourself or paying > someone else. The work to try and keep software 'stable' over a 6 > month lifetime seems to grow exponentially so that by the end of the 3 > years it is 1000 times harder than it was in the beginning. Now the > number of people who are wanting to work on this older software for > free (or if they are doing it for themselves to share it for "free") > is incredibly small. I expect that we are looking at 10 packages in > EPEL maybe? So we are going to be looking at rebasing and updates > every 2-3 years no matter what for the majority of software. Expecting > it not to be like that is Cnut's tidal problem. > > > https://en.wikipedia.org/wiki/King_Canute_and_the_waves > As mentioned several times already, EPEL means different things to different people. To me stability is significantly more important than having the latest and greatest, so for a fair number of packages that means "just leave things alone" and the "waves" are self inflicted. But as was also mentioned, a lot of packages have jumped on the Chrome bandwagon with crazy release cycles and maintaining security fixes in those cases is basically impossible for a volunteer effort. From my perspective, having a policy that "discourages but allows updates" with a very deliberate and controlled process is the right model for EPEL. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL Proposal #1: Rechartering
On Thu, 18 Feb 2016 17:22:07 -0700 Stephen John Smoogenwrote: > One of the issues that I am finding is that most software these days > has only a 3 year lifetime at best.. if you want it to be longer you > are going to pay for it either by maintaining it yourself or paying > someone else. The work to try and keep software 'stable' over a 6 > month lifetime seems to grow exponentially so that by the end of the 3 > years it is 1000 times harder than it was in the beginning. Now the > number of people who are wanting to work on this older software for > free (or if they are doing it for themselves to share it for "free") > is incredibly small. I expect that we are looking at 10 packages in > EPEL maybe? So we are going to be looking at rebasing and updates > every 2-3 years no matter what for the majority of software. Expecting > it not to be like that is Cnut's tidal problem. > > > https://en.wikipedia.org/wiki/King_Canute_and_the_waves An additional issue with SCL's is that we have no guidelines on them. While I suppose EPEL could add them with it's own guidelines, I would be against that given that Fedora couldn't finalize them. kevin pgppUFRfzVHQf.pgp Description: OpenPGP digital signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL Proposal #1: Rechartering
On February 18, 2016 7:08:34 PM PST, Michael Stahnkewrote: >I was trying to reply to everything inline, but being the responsible >posters ya'll are, you trimmed and everything leaving context harder to >just jump in on :) > >Way back in the day when I had a lot more time to spend on EPEL, I >loved >it. There were a few assumptions made then that I think don't hold up >now. > >1. 5 year lifecycle. 5 years is doable in a stretch by some >maintainers. >Now, it's 10 or 13 years depending on how you slice your RHEL support. >That's too long for any volunteer. >2. Upstreams move a heck of a lot faster. As users/developers started >trusting update mechansims more and speed/agility were seen as good >rather >than anti-stable, upstreams started moving. That means a LONG support >release from some upstream players might be 18 months vs 4 years in the >mid >2000s. A large part of that, too, has been the widespread implementation of CI testing. There are fewer and fewer packages that consider any branch "unstable" anymore. > >Those two assumptions not holding up are enough of a reason to >recharter. > >One thing I wished we had done early on was attract EPEL maintainers or >separate from Fedora where desired. I found that lots of people only >wanted >to maintain packages in Fedora. They didn't care about EPEL at all. I >found >that people who really cared about the EL stack, didn't care about >Fedora, >but to help with EPEL, you had to be a Fedora person. I am not sure on >the >status of all that any more (cause I'm delinquent and way less active >than >I probably should be), but if that's still the case, could that be >fixed in >any way? Now that CentOS is under the RH umbrella it seems like there >could >be an enterprise community contributor worflow/org/group thing. >(Apologies >if there already is, again, I'm just popping my head back up after a >while >away). > > >> >> > > >> But by 2013, virtually all Red Hat major accounts (at least all I was >> exposed to) _outlawed_ EPEL from being enabled at all, because of the >> endless conflicts with countless, various Red Hat products. >> >> So ... today, in 2016, it doesn't really matter. Back in 2012, I was >> more worried about EPEL becoming something customers cannot enable. >> But that's now the reality. >> >> FWIW, I haven't seen this reaction, but a few anecdotes are also not >data. I do think as the OS has become more commoditized and the >layered >products have become the differentiator, this is more of a truism >though, >and should be planned for. Most people I see now mirror parts of EPEL >and >their own packages and other stuff and slam that all together into >their >package sets. > > > > >___ >epel-devel mailing list >epel-devel@lists.fedoraproject.org >http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL Proposal #1: Rechartering
On 18 February 2016 at 16:37, Dave Johansenwrote: > On Thu, Feb 18, 2016 at 3:54 PM, Bryan J Smith wrote: >> >> Dave Johansen wrote: >> > RHSCL is a non-starter where I work (and I imagine at other >> > locations). 2-3 years of support just isn't enough to make it a >> > worthwhile investment. >> >> Well, there usually _is_ more than one (1) [RH]SCL per RHEL release. >> So it's more like 2-3 releases that "rebase" every 2+ years, for 6-7 >> years total of the RHEL release. >> >> The idea here is that you have up to three (3) years to "rebase." ;) >> >> Not that [RH]SCL is 3 years and that's it. I mean ... understand my >> intent here. Sustaining engineering is _not_ free, it's _not_ >> upstream, and people should be expected to rebase every 2-3 years, >> when it comes closer to Upstream. >> >> Again, understand the "bigger picture" of my "suggestion." >> >> > For example, we just barely started upgrading to EL 7 ... (cut) >> >> _So_ you will likely be on the _second_ [RH]SCL release for RHEL 7, >> instead of the _first_. So ... what's the problem? >> >> So ... I have to now ask ... have you used [RH]SCL? ;) >> >> I.e., Again, it's _not_ only 3 years of RHEL, but 3 years per release, >> with each RHEL releases getting 2-3 releases over 6-7 years. >> >> Ergo ... > > > SCL is an AWESOME idea, but for our organization, having to jump to the next > version of an SCL every 2-3 years just isn't possible. We use RHEL because > of its long support life cycle and starting to use the SCL breaks that idea. > If SCL had a lifecycle more akin to RHEL (i.e. something like release half > as often and support for twice as long), then it would be a different story. > One of the issues that I am finding is that most software these days has only a 3 year lifetime at best.. if you want it to be longer you are going to pay for it either by maintaining it yourself or paying someone else. The work to try and keep software 'stable' over a 6 month lifetime seems to grow exponentially so that by the end of the 3 years it is 1000 times harder than it was in the beginning. Now the number of people who are wanting to work on this older software for free (or if they are doing it for themselves to share it for "free") is incredibly small. I expect that we are looking at 10 packages in EPEL maybe? So we are going to be looking at rebasing and updates every 2-3 years no matter what for the majority of software. Expecting it not to be like that is Cnut's tidal problem. https://en.wikipedia.org/wiki/King_Canute_and_the_waves -- Stephen J Smoogen. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL Proposal #1: Rechartering
Dave Johansen wrote: > RHSCL is a non-starter where I work (and I imagine at other > locations). 2-3 years of support just isn't enough to make it a > worthwhile investment. Well, there usually _is_ more than one (1) [RH]SCL per RHEL release. So it's more like 2-3 releases that "rebase" every 2+ years, for 6-7 years total of the RHEL release. The idea here is that you have up to three (3) years to "rebase." ;) Not that [RH]SCL is 3 years and that's it. I mean ... understand my intent here. Sustaining engineering is _not_ free, it's _not_ upstream, and people should be expected to rebase every 2-3 years, when it comes closer to Upstream. Again, understand the "bigger picture" of my "suggestion." > For example, we just barely started upgrading to EL 7 ... (cut) _So_ you will likely be on the _second_ [RH]SCL release for RHEL 7, instead of the _first_. So ... what's the problem? So ... I have to now ask ... have you used [RH]SCL? ;) I.e., Again, it's _not_ only 3 years of RHEL, but 3 years per release, with each RHEL releases getting 2-3 releases over 6-7 years. Ergo ... > For most packages, leaving the version that's there alone is probably > a decent solution, but for packages where security fixes continue to > happen and are important, then an "official" upgrade path would be > good. Maybe something like: > 1) Current maintainer identifies upgraded version and reason for update > (hopefully limited to security fixes or something along those lines and not > just "I want a newer version"), > 2) Notifies intention on mailing list, > 3) Feedback from community, and > 4) Perform upgrade Which works out very well for something that rebases every 2-3 years ... like [RH]SCL. Again, I wasn't trying to say "be like [RH]SCL," but more like, "Here's a Red Hat add-on that kinda already has this 'lifecycle' that Red Hat customers would understand." -- bjs -- Bryan J Smith - http://www.linkedin.com/in/bjsmith ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL Proposal #1: Rechartering
On Thu, Feb 18, 2016 at 2:39 PM, Bryan J Smithwrote: > Stephen John Smoogen wrote: > > 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). > > I can only imagine how difficult this gets for EPEL maintainers, even > the ones with the RHEL Developer Suite subscription. There are just a > lot of add-ons and channels to track, even ones not in the RHEL Dev. > > As I've mentioned in years prior, the only way to prevent this is for > the CentOS team to build everything, and that's a tall order, and only > getting to be a bigger and bigger task by the day. So EPEL is really > one of those things that Red Hat customers pull down, but don't enable > ... until something specifically is needed, and then it's checked for > conflicts, and only on a small subset of systems. > > Non-Red Hat customers running CentOS usually have a much easier task > of enabling EPEL, although there can still be some issues. > > > And this is where I made things worse by conflicting with channels > > versus "entire OS" > > I don't think there is a perfect answer that satisfies all, and never > will be. And definitely not 4-5 years into where EPEL is today, from > where the Red Hat product line went more and more vertical than it > ever was before. > > It's one of those things that people have just accepted. Although it > is good for maintainers to recognize that the EPEL build system is > going to -- gasp -- build against Red Hat packages, and not CentOS. ;) > > > 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. > > Maybe I'm throwing this out in ignorance ... > > But maybe [Red Hat] Software Collections ([RH]SCL) offers a baseline > for a "reasonable lifecycle" that should be a target? I.e., 3 years. > > E.g., any software that makes it into EPEL will have a "soft target" > of at least 3 years support? > RHSCL is a non-starter where I work (and I imagine at other locations). 2-3 years of support just isn't enough to make it a worthwhile investment. For example, we just barely started upgrading to EL 7 and it will be years until a sizable portion of our machines have moved to EL 7 (we still have quite a few EL 5 boxes). For most packages, leaving the version that's there alone is probably a decent solution, but for packages where security fixes continue to happen and are important, then an "official" upgrade path would be good. Maybe something like: 1) Current maintainer identifies upgraded version and reason for update (hopefully limited to security fixes or something along those lines and not just "I want a newer version"), 2) Notifies intention on mailing list, 3) Feedback from community, and 4) Perform upgrade Something like this could potentially get maintainers to step up that are willing to continue maintaining the current version. But in most cases, I'm guessing this wouldn't happen but would give an official process and expected timeline for user users. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL Proposal #1: Rechartering
Stephen John Smoogen wrote: > 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). I can only imagine how difficult this gets for EPEL maintainers, even the ones with the RHEL Developer Suite subscription. There are just a lot of add-ons and channels to track, even ones not in the RHEL Dev. As I've mentioned in years prior, the only way to prevent this is for the CentOS team to build everything, and that's a tall order, and only getting to be a bigger and bigger task by the day. So EPEL is really one of those things that Red Hat customers pull down, but don't enable ... until something specifically is needed, and then it's checked for conflicts, and only on a small subset of systems. Non-Red Hat customers running CentOS usually have a much easier task of enabling EPEL, although there can still be some issues. > And this is where I made things worse by conflicting with channels > versus "entire OS" I don't think there is a perfect answer that satisfies all, and never will be. And definitely not 4-5 years into where EPEL is today, from where the Red Hat product line went more and more vertical than it ever was before. It's one of those things that people have just accepted. Although it is good for maintainers to recognize that the EPEL build system is going to -- gasp -- build against Red Hat packages, and not CentOS. ;) > 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. Maybe I'm throwing this out in ignorance ... But maybe [Red Hat] Software Collections ([RH]SCL) offers a baseline for a "reasonable lifecycle" that should be a target? I.e., 3 years. E.g., any software that makes it into EPEL will have a "soft target" of at least 3 years support? Just a suggestion ... one that RHSCL users are familiar with. I think it's unreasonable to expect updates beyond that, or at least not without a rebase after 3 years. As always, just my $0.02 ... from a Red Hat customer standpoint, not a community one. -- Bryan J Smith - http://www.linkedin.com/in/bjsmith ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL Proposal #1: Rechartering
On 18 February 2016 at 12:56, Kevin Fenziwrote: > >> 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
[EPEL-devel] Re: EPEL Proposal #1: Rechartering
On Thu, 18 Feb 2016 12:11:28 -0800 Joe Julianwrote: > On February 18, 2016 11:56:54 AM PST, Kevin Fenzi > wrote: > >On Tue, 16 Feb 2016 23:24:58 -0700 > >Stephen John Smoogen wrote: > > > >...snip... > > > >> 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" > > > Even that's not always feasible, like when RHEL suddenly started > including the RHGS-only gluster client. True. I recall someone getting on my case about the 'never' when there's often overlap because RHEL does something and we don't notice it right away. So, how about: "EPEL strives to provide packages that do not conflict with or replace the packages in the RHEL channels that it builds against. From time to time such packages may be in the collection, but will be removed in a timely manner" There's 0 chance we can always not be conflicting unless we somehow knew in advance any changes and had things ready for them when they changed. kevin pgp7Zn60a5FBL.pgp Description: OpenPGP digital signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL Proposal #1: Rechartering
On Tue, 16 Feb 2016 23:24:58 -0700 Stephen John Smoogenwrote: ...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