Greetings.
In the meeting today we discussed when to move EPEL6 out of beta, now that RHEL6 final is out. In the past we had said "when CentOS6 is out", mostly in order to give time after final to build things up, etc.
Moving out of Beta means: We would start using bodhi for all updates, The 2 weeks in testing before going stable would be enforced, We would have epel and epel-testing repos in our release package, buildroot overrides would be needed if you wanted to build against a newly built package, etc.
What do folks think on when we should move out of Beta mode:
a) When CentOS6 is out.
b) 1 month after RHEL6 was released.
c) NOW!
d) Something else.
IMHO it's nice to give a bit of time now that we know the final package list in RHEL6 to branch and build items. Also, some EPEL folks may want to make sure they have the very latest (stable) items built that they are willing to try and support for the RHEL6 life time.
Feedback welcome.
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/15/2010 04:54 PM, Kevin Fenzi wrote:
Greetings.
In the meeting today we discussed when to move EPEL6 out of beta, now that RHEL6 final is out. In the past we had said "when CentOS6 is out", mostly in order to give time after final to build things up, etc.
Moving out of Beta means: We would start using bodhi for all updates, The 2 weeks in testing before going stable would be enforced, We would have epel and epel-testing repos in our release package, buildroot overrides would be needed if you wanted to build against a newly built package, etc.
What do folks think on when we should move out of Beta mode:
a) When CentOS6 is out.
b) 1 month after RHEL6 was released.
c) NOW!
d) Something else.
IMHO it's nice to give a bit of time now that we know the final package list in RHEL6 to branch and build items. Also, some EPEL folks may want to make sure they have the very latest (stable) items built that they are willing to try and support for the RHEL6 life time.
I vote for b) with the below as rationale:
As a related question: for EPEL 6 can we discuss the possibility of having EPEL6.1, EPEL6.2 releases where we consider the possibility of releasing minor and (possibly) major package updates?
RHEL itself will sometimes rev minor and major versions of packages during Y-stream releases (6.1, 6.2, etc.) I personally think that we should consider doing something similar in EPEL. One month after each RHEL Y-stream release, we should allow similar updates to happen in EPEL.
Logistically, I'd be suggesting that we should maintain a primary EPEL6 branch and an ongoing EPEL6-beta branch. Individual packages could then be merged into the EPEL6 primary branch one month or so after a RHEL Y-stream release.
It would make maintaining packages for EPEL a lot more approachable if there was a plan for when it would be okay to have new functionality updates. It would also be predictable from a consumer's perspective.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On Nov 15, 2010, at 4:03 PM, Stephen Gallagher wrote:
I vote for b) with the below as rationale:
As a related question: for EPEL 6 can we discuss the possibility of having EPEL6.1, EPEL6.2 releases where we consider the possibility of releasing minor and (possibly) major package updates?
RHEL itself will sometimes rev minor and major versions of packages during Y-stream releases (6.1, 6.2, etc.) I personally think that we should consider doing something similar in EPEL. One month after each RHEL Y-stream release, we should allow similar updates to happen in EPEL.
Logistically, I'd be suggesting that we should maintain a primary EPEL6 branch and an ongoing EPEL6-beta branch. Individual packages could then be merged into the EPEL6 primary branch one month or so after a RHEL Y-stream release.
It would make maintaining packages for EPEL a lot more approachable if there was a plan for when it would be okay to have new functionality updates. It would also be predictable from a consumer's perspective.
On the subject of point releases... but not exactly the same reasoning... I've brought up the idea of supporting EUS (z-stream) in the past which was more or less shot down. Being that we are still in EPEL 6 beta times... I figure its worth asking again, is there any thoughts of supporting EUS? Currently, if any RHEL users out there are using EPEL base on an older EUS point release (like 5.4z) ... some things have the potential to break (memcached due to libevent, etc).
The reason I ask is... if we build out the capability to build against up coming point releases separately, how much more work would it be to keep older point releases around... allowing EUS users to access EPEL 6.x for packages that are built against their EUS point release.
Just thought I'd throw that into the mix.
--- derks
On Mon, 15 Nov 2010 16:44:36 -0600 BJ Dierkes wdierkes@5dollarwhitebox.org wrote:
On the subject of point releases... but not exactly the same reasoning... I've brought up the idea of supporting EUS (z-stream) in the past which was more or less shot down. Being that we are still in EPEL 6 beta times... I figure its worth asking again, is there any thoughts of supporting EUS? Currently, if any RHEL users out there are using EPEL base on an older EUS point release (like 5.4z) ... some things have the potential to break (memcached due to libevent, etc).
Well, we don't even do point releases... this would be another layer on top of those? So, EL-5.1z / EL-5.1 / EL-5.2z / EL-5.2 ?
The reason I ask is... if we build out the capability to build against up coming point releases separately, how much more work would it be to keep older point releases around... allowing EUS users to access EPEL 6.x for packages that are built against their EUS point release.
About 2x as much? or more?
kevin
On Mon, 15 Nov 2010 17:03:49 -0500 Stephen Gallagher sgallagh@redhat.com wrote:
I vote for b) with the below as rationale:
As a related question: for EPEL 6 can we discuss the possibility of having EPEL6.1, EPEL6.2 releases where we consider the possibility of releasing minor and (possibly) major package updates?
This would be a lot more infrastructure work I fear...
RHEL itself will sometimes rev minor and major versions of packages during Y-stream releases (6.1, 6.2, etc.) I personally think that we should consider doing something similar in EPEL. One month after each RHEL Y-stream release, we should allow similar updates to happen in EPEL.
Logistically, I'd be suggesting that we should maintain a primary EPEL6 branch and an ongoing EPEL6-beta branch. Individual packages could then be merged into the EPEL6 primary branch one month or so after a RHEL Y-stream release.
So how would that work for the git/repo/build side? each package would have a EL-5.1/EL-5.2/EL-5.3/EL-5.4/EL-5.5/etc branch? If you wanted to update them all thats 6-9 builds?
It would make maintaining packages for EPEL a lot more approachable if there was a plan for when it would be okay to have new functionality updates. It would also be predictable from a consumer's perspective.
So, a new minor rev would allow any new feature, but you would have to keep the old rev on the old version? Couldn't that get confusing? Would we need bug components then for each of the streams then I guess?
I think it could be ok, but not sure we have the infrastructure manpower for it.
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/16/2010 12:31 AM, Kevin Fenzi wrote:
On Mon, 15 Nov 2010 17:03:49 -0500 Stephen Gallagher sgallagh@redhat.com wrote:
I vote for b) with the below as rationale:
As a related question: for EPEL 6 can we discuss the possibility of having EPEL6.1, EPEL6.2 releases where we consider the possibility of releasing minor and (possibly) major package updates?
This would be a lot more infrastructure work I fear...
RHEL itself will sometimes rev minor and major versions of packages during Y-stream releases (6.1, 6.2, etc.) I personally think that we should consider doing something similar in EPEL. One month after each RHEL Y-stream release, we should allow similar updates to happen in EPEL.
Logistically, I'd be suggesting that we should maintain a primary EPEL6 branch and an ongoing EPEL6-beta branch. Individual packages could then be merged into the EPEL6 primary branch one month or so after a RHEL Y-stream release.
So how would that work for the git/repo/build side? each package would have a EL-5.1/EL-5.2/EL-5.3/EL-5.4/EL-5.5/etc branch? If you wanted to update them all thats 6-9 builds?
It would make maintaining packages for EPEL a lot more approachable if there was a plan for when it would be okay to have new functionality updates. It would also be predictable from a consumer's perspective.
So, a new minor rev would allow any new feature, but you would have to keep the old rev on the old version? Couldn't that get confusing? Would we need bug components then for each of the streams then I guess?
I think it could be ok, but not sure we have the infrastructure manpower for it.
Not exactly. I'm talking about maybe maintaining only the two most recent point releases at a time, similar to the Fedora process.
So basically we'd only ever have three branches: the beta branch and the two most recent stable branches.
EL-6.1, EL-6.2 and EL-beta (the last of which would become EL-6.3 one month after RHEL/CentOS 6.3 released and we'd terminate support for EL6.1 at this time as well).
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Once upon a time, Kevin Fenzi kevin@scrye.com said:
In the meeting today we discussed when to move EPEL6 out of beta, now that RHEL6 final is out. In the past we had said "when CentOS6 is out", mostly in order to give time after final to build things up, etc.
Why should EPEL wait for CentOS? If there is a valid reason to wait some time, that should be used as the metric, not when another group gets their release done (this gets back to my "is EPEL's primary target RHEL or CentOS - it can't be both" question from a few months back).
b) 1 month after RHEL6 was released.
Is there a particular reason to wait? Is specific additional testing being done, with results being used to determine overall status?
If not, I don't see any reason to wait, especially an arbitrary period of time. Release it now.
Some things may not be there at release time, but again, unless EPEL is going to be held up for those packages, there's no point in waiting.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/15/2010 04:22 PM, Chris Adams wrote:
If not, I don't see any reason to wait, especially an arbitrary period of time. Release it now.
Some things may not be there at release time, but again, unless EPEL is going to be held up for those packages, there's no point in waiting.
I think part of the reason is that non-RHT customers have no binaries in which to test their builds upon. Ballparking here, but I think not a small amount of EPEL packagers are CentOS (or other) users and not RHEL users.
That said, I think it would be quite fair to grant each EPEL packager with a RHEL developer entitlement which could be used to test their builds upon.
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On Mon, Nov 15, 2010 at 17:29, Jesse Keating jkeating@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/15/2010 04:22 PM, Chris Adams wrote:
If not, I don't see any reason to wait, especially an arbitrary period of time. Release it now.
Some things may not be there at release time, but again, unless EPEL is going to be held up for those packages, there's no point in waiting.
I think part of the reason is that non-RHT customers have no binaries in which to test their builds upon. Ballparking here, but I think not a small amount of EPEL packagers are CentOS (or other) users and not RHEL users.
The last time I checked it was 75% were CentOS users but that was around 5 came out.
That said, I think it would be quite fair to grant each EPEL packager with a RHEL developer entitlement which could be used to test their builds upon.
Good luck with that :).
Once upon a time, Jesse Keating jkeating@redhat.com said:
I think part of the reason is that non-RHT customers have no binaries in which to test their builds upon. Ballparking here, but I think not a small amount of EPEL packagers are CentOS (or other) users and not RHEL users.
I've probably come off sounding short/argumentative in this, and I want to apologize for that. I'm really just trying to figure out the reasons behind the choices and decisions.
What does "released" mean for EPEL? AFAIK it doesn't mean "100% packages available". There is a set of packages that are (or at least are believed to be) ready now; why not release them now? If someone is waiting on CentOS to get their packages ready, that's okay; those packages won't be in the EPEL 6 release tree until they are.
That's why I asked if there is some metric to use to decide when EPEL is "ready". If it is X% of packages, or certain "major" packages, that should be documented somewhere, and then when that point is reach, EPEL can be released. I don't see any reason for just waiting an arbitrary amount of time (what if nothing really changes in a month?).
EPEL doesn't have separate release and updates trees; there's just the EPEL tree. Packages are added as somebody picks them up, so I would say just release what is considered ready now and let EPEL 6 grow over time (just like previous EPEL versions have done).
That said, I think it would be quite fair to grant each EPEL packager with a RHEL developer entitlement which could be used to test their builds upon.
That would be nice, although it would probably require some minimum level of commitment (e.g. not people like me that only maintain a couple of very minor packages, and otherwise just agitate in Bugzilla and on mailing lists :-) ).
I still think some clear direction about which OS is the primary target for EPEL (RHEL or CentOS) should be stated. Since CentOS will always lag RHEL (not through any failure of CentOS; it is just a fact), EPEL can either target RHEL and update things when new RHEL updates come out that require EPEL changes, or wait until CentOS gets the compatible update in place. You can't have it both ways, at least not for the same packages, and I would think the policy should be the same for all of EPEL.
CentOS also already has its own set of add-on repos (although not near as large as EPEL) that have some overlap with EPEL. My personal preference (of course because I use RHEL) would be for EPEL to stay current with RHEL, rather than wait for CentOS.
For example, in the situation where RHEL releases a backwards incompatible security update that requires an updated EPEL package, but the EPEL package is waiting for CentOS, a "yum update" will not load the RHEL security update unless you first remove the old EPEL package, blocking the update from RHEL users.
On the other hand, if the EPEL package is updated before CentOS gets the security update, the CentOS users can use --skip-broken to just skip the EPEL update they can't yet load, and RHEL users can load all their updates. Once CentOS gets the update, they'll get the EPEL update as well. I think that's a better situation.
On Mon, 15 Nov 2010 23:08:22 -0600 Chris Adams cmadams@hiwaay.net wrote:
...snip...
What does "released" mean for EPEL? AFAIK it doesn't mean "100% packages available". There is a set of packages that are (or at least are believed to be) ready now; why not release them now? If someone is waiting on CentOS to get their packages ready, that's okay; those packages won't be in the EPEL 6 release tree until they are.
Well, it means the ones in now are the ones we will try and stick with for the next 7 years. ;)
That's why I asked if there is some metric to use to decide when EPEL is "ready". If it is X% of packages, or certain "major" packages, that should be documented somewhere, and then when that point is reach, EPEL can be released. I don't see any reason for just waiting an arbitrary amount of time (what if nothing really changes in a month?).
No metric that I know of... we were asking for more feedback on this from the list, since we have never done this before. ;) EPEL was created after RHEL5 was out, so we never have created a new EPEL release after a RHEL came out. ;) Help us decide what makes sense.
EPEL doesn't have separate release and updates trees; there's just the EPEL tree. Packages are added as somebody picks them up, so I would say just release what is considered ready now and let EPEL 6 grow over time (just like previous EPEL versions have done).
ok.
...snip..
I still think some clear direction about which OS is the primary target for EPEL (RHEL or CentOS) should be stated. Since CentOS will always lag RHEL (not through any failure of CentOS; it is just a fact), EPEL can either target RHEL and update things when new RHEL updates come out that require EPEL changes, or wait until CentOS gets the compatible update in place. You can't have it both ways, at least not for the same packages, and I would think the policy should be the same for all of EPEL.
Agreed. I think We should follow RHEL in most cases, but consider CentOS if there's some way we can help out or serve our centos users. We already do this for example with the buildsystem. We build against RHEL, and update as soon as the RHEL version is out, not waiting for CentOS.
All good feedback. Thanks.
kevin
On Mon, Nov 15, 2010 at 10:44:19PM -0700, Kevin Fenzi wrote:
On Mon, 15 Nov 2010 23:08:22 -0600 Chris Adams cmadams@hiwaay.net wrote:
...snip...
What does "released" mean for EPEL? AFAIK it doesn't mean "100% packages available". There is a set of packages that are (or at least are believed to be) ready now; why not release them now? If someone is waiting on CentOS to get their packages ready, that's okay; those packages won't be in the EPEL 6 release tree until they are.
Well, it means the ones in now are the ones we will try and stick with for the next 7 years. ;)
This is what I fear the most.... but waiting might not make it any better.
Maybe a better strategy would have been to not mass branch any EPEL packages or to tell people *not* to build unless they were at the stage that they were ready to support for the next 7 years whether or not it had a branch.
-Toshio
Well, it means the ones in now are the ones we will try and stick with for the next 7 years. ;)
<snip>
I think the 7 year plan is a bit difficult for most maintainers. I love the idea of minimal breakage though. We need to remind users to subscribe to epel-announce because from time to time, there will be breakage, whether it's due to dead upstream, security fixes or something else, it will happen. It sucks, and we try to avoid it, but minimal does not mean zero.
As for releasing EPEL6 and when, I'd like to wait a bit more. I love not having to override buildroots right now for builds and deps. Also, we can't run repoclosure until CentOS is out, at least the way it is currently being done for EPEL4/5.
Keep in mind that while 6 has been released, many organizations will put it in a lab, and play with it for months before really hitting it hard and in production. I know my company probably won't have large-scale production applications on 6 for at least a year. I'm sure other shops are faster, but if you want to jump on a stable enterprise product as fast as possible, then I assume you have the means to build up your needed catalog of RPMS and management software.
I'm not saying we should wait a year for EPEL6 to be considered ready to go, but 60 days might not be too much.
Just my 2 cents,
stahnma
On Mon, Nov 15, 2010 at 11:08:22PM -0600, Chris Adams wrote:
On the other hand, if the EPEL package is updated before CentOS gets the security update, the CentOS users can use --skip-broken to just skip the EPEL update they can't yet load, and RHEL users can load all their updates. Once CentOS gets the update, they'll get the EPEL update as well. I think that's a better situation.
This only works if the package with a incompatible update in EPEL is in the base or core group, i.e. always installed. Otherwise you would block installing the package at all from EPEL for CentOS users.
E.g. foo-1 is in EPEL and is updated to foo-2, requiring bar-2 from RHEL which is not in CentOS. Then fresh installs of CentOS won't be able to install package foo from EPEL, because yum would try to install foo-2 which fails.
Regards Till
On Mon, 15 Nov 2010 18:22:58 -0600 Chris Adams cmadams@hiwaay.net wrote:
b) 1 month after RHEL6 was released.
Is there a particular reason to wait? Is specific additional testing being done, with results being used to determine overall status?
No, but now the final list of available packages is known and versions, so people can decide what EPEL version of something they can build and support for the next 7 years. Some packages, like fftw were in limbo or not available, so now those folks that needed that package can build out their apps.
Granted this could be done on the fly as we go to, but we sort of 'lock in' to the version at stable release time, so it would be nice to give maintainers a chance to lock in to the version they want/can.
If not, I don't see any reason to wait, especially an arbitrary period of time. Release it now.
Some things may not be there at release time, but again, unless EPEL is going to be held up for those packages, there's no point in waiting.
Sure, true to some extent...
kevin
On Mon, Nov 15, 2010 at 22:38, Kevin Fenzi kevin@scrye.com wrote:
On Mon, 15 Nov 2010 18:22:58 -0600 Chris Adams cmadams@hiwaay.net wrote:
b) 1 month after RHEL6 was released.
Is there a particular reason to wait? Is specific additional testing being done, with results being used to determine overall status?
No, but now the final list of available packages is known and versions, so people can decide what EPEL version of something they can build and support for the next 7 years. Some packages, like fftw were in limbo or not available, so now those folks that needed that package can build out their apps.
After doing this for 4 years.. I think that for the small number of people we have the idea that we can support without resources packages for 7 years without major updates is wishful thinking. We have a ton of packages that get updated almost as much as rawhide already :/.
However that is really a different topic and I am a grumpy old man with bursitis at the moment.
On 11/15/2010 2:54 PM, Kevin Fenzi wrote:
Greetings.
In the meeting today we discussed when to move EPEL6 out of beta, now that RHEL6 final is out. In the past we had said "when CentOS6 is out", mostly in order to give time after final to build things up, etc.
Moving out of Beta means: We would start using bodhi for all updates, The 2 weeks in testing before going stable would be enforced, We would have epel and epel-testing repos in our release package, buildroot overrides would be needed if you wanted to build against a newly built package, etc.
What do folks think on when we should move out of Beta mode:
a) When CentOS6 is out.
b) 1 month after RHEL6 was released.
c) NOW!
d) Something else.
IMHO it's nice to give a bit of time now that we know the final package list in RHEL6 to branch and build items. Also, some EPEL folks may want to make sure they have the very latest (stable) items built that they are willing to try and support for the RHEL6 life time.
Some kind of delay would be good. fftw just now showed up so there will be a number of scientific packages to be built, and it would ease that. I'd like to see one more list of packages not built yet too. But I could see 2-4 weeks being fine. Although, I won't be able to test out my packages outside of the build system until Centos 6 is out.
- Orion
Once upon a time, Orion Poplawski orion@cora.nwra.com said:
Some kind of delay would be good. fftw just now showed up so there will be a number of scientific packages to be built, and it would ease that.
I guess I don't see why the packages that are ready can't be released. Just because it is "released" doesn't mean that every package from EPEL 5 is available for EPEL 6.
On Mon, 15 Nov 2010 22:46:55 -0600 Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Orion Poplawski orion@cora.nwra.com said:
Some kind of delay would be good. fftw just now showed up so there will be a number of scientific packages to be built, and it would ease that.
I guess I don't see why the packages that are ready can't be released. Just because it is "released" doesn't mean that every package from EPEL 5 is available for EPEL 6.
Well, the packages are 'released'.
http://mirrors.tummy.com/pub/fedora.redhat.com/epel/beta/6/
They just have the word 'beta' in the url and the release process is more lax than in a 'stabe' epel release. You can use and test and provide feedback.
kevin
On 11/15/2010 10:26 PM, Kevin Fenzi wrote:
On Mon, 15 Nov 2010 22:46:55 -0600 Chris Adamscmadams@hiwaay.net wrote:
Once upon a time, Orion Poplawskiorion@cora.nwra.com said:
Some kind of delay would be good. fftw just now showed up so there will be a number of scientific packages to be built, and it would ease that.
I guess I don't see why the packages that are ready can't be released. Just because it is "released" doesn't mean that every package from EPEL 5 is available for EPEL 6.
Well, the packages are 'released'.
http://mirrors.tummy.com/pub/fedora.redhat.com/epel/beta/6/
They just have the word 'beta' in the url and the release process is more lax than in a 'stabe' epel release. You can use and test and provide feedback.
It is easier to build dependency chains now as the build automatically go into the build root. Don't need bodhi or build-root overrides.
On 15 November 2010 22:54, Kevin Fenzi kevin@scrye.com wrote:
What do folks think on when we should move out of Beta mode:
a) When CentOS6 is out.
b) 1 month after RHEL6 was released.
I'm happy with either of these. I would prefer to see a delay for now, simply because there are a number of trees of packages that have been waiting on finding out exactly what's available from RHEL6. Chunks of our ruby and perl stacks for example. If we can delay by period X and get 90% built within 1 month rather than release now with about 60% (last I looked) and it take 3 months for the next 30 because of delays getting things into the build roots, then I think this is a win.
I'll try to generate the numbers and reminders sooner rather than later...
For the RHEL users who want EPEL sooner rather than later maybe we could simply symlink to the location where EPEL-6 will reside long term?
Mark
epel-devel@lists.fedoraproject.org
-
BJ Dierkes -
Chris Adams -
Jesse Keating -
Kevin Fenzi -
Mark Chappell -
Mathieu Baudier -
Michael Stahnke -
Orion Poplawski -
Remi Collet -
Stephen Gallagher -
Stephen John Smoogen -
Till Maas -
Toshio Kuratomi