[EPEL-devel] Re: EPEL Proposal #1: Rechartering

[Bryan J Smith]

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

[Ken Dreyer]

On Fri, Feb 26, 2016 at 2:38 PM, Felix Schwarz
 wrote:
> 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

[Felix Schwarz]

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

[Dave Johansen]

On Thu, Feb 18, 2016 at 5:22 PM, Stephen John Smoogen 
wrote:

> 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

[Kevin Fenzi]

On Thu, 18 Feb 2016 17:22:07 -0700
Stephen John Smoogen  wrote:

> 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

[Joe Julian]

On February 18, 2016 7:08:34 PM PST, Michael Stahnke  
wrote:
>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

[Stephen John Smoogen]

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

-- 
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

[Bryan J Smith]

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

[Dave Johansen]

On Thu, Feb 18, 2016 at 2:39 PM, Bryan J Smith  wrote:

> 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

[Bryan J Smith]

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

[Stephen John Smoogen]

On 18 February 2016 at 12:56, Kevin Fenzi  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 

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

[Kevin Fenzi]

On Thu, 18 Feb 2016 12:11:28 -0800
Joe Julian  wrote:

> 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

[Kevin Fenzi]

On Tue, 16 Feb 2016 23:24:58 -0700
Stephen John Smoogen  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