Greetings.
As you may know, we had a EPEL session on last friday at fudcon lawerence to try and discuss outstanding issues, etc.
On the question of overlaps, it seemed like to me most people were fine with striving to not overlap with baseos, optional, ha and lb. So, unless someone strongly objects, I think we should just adopt that policy.
On the question of incompatible upgrades, things were much less clear. There was a suggestion of using SCL (software collections) to help with this case, but I don't actually think it helps us too much.
Consider the following four ideas:
1) incompatible upgrades have to create a parallel install-able package and only users who know it exists switch to it when they want. example: mediawiki116, mediawiki117, etc
2) incompatible upgrades are made in a epel-rawhide repo that moves faster than regular. Users would need to know it exists and pull that package from there instead of the normal repo.
3) incompatible upgrades are made with software collections. User has to explicitly change their install to switch to the new one when they want.
4) incompatible upgrades are marked in bodhi and a yum plugin sees them and stops updates until the maintainer wishes them.
idea 1 means more work for the maintainer to make the new package. idea 2 means more work for releng. idea 3 means a bit more work for maintainers idea 4 means more work for releng, more work for a yum plugin writer, and could be bypassed by people not using the plugin.
but all of them mean the user doesn't get the new thing until they know about it/switch, meaning they could still be using the old thing that never gets bugfixes.
A lot of people seemed to agree that the root of the problem wasn't the technical details, but more the expectations. When EPEL was started long ago it was "best effort" and we knew some things were simply not going to be able to be supported for 5 years or 7 or 10. The perception seems to have drifted over to more 'epel will strive to support this old thing for the life of the rhel release' or 'epel will never push an incompatible upgrade' or 'epel maintainers are perfect and they have nice hair too!'.
So, I'd like to propose the following:
a) adjust documentation/announce a reminder from time to time that EPEL is a volunteer, best effort collection of packages. From time to time incompatible upgrades will happen, please watch the epel-announce list and gate your epel updates as your needs require.
b) Maintainers should try not to push incompatible upgrades, however if they feel that is the only way forward, they can. When doing so they must:
1) announce their intention as much in advance as they know it to epel-announce, and their reasons for having to do this. 2) announce again when the package is in epel-testing.
For that to work we would need to watch out for incompatible upgrades that were not announced. I'm not sure how to do this aside from asking folks enable epel-test on some machines and test updates more, and try 'best effort' some more.
Thoughts? screams?
kevin
Once upon a time, Kevin Fenzi kevin@scrye.com said:
b) Maintainers should try not to push incompatible upgrades, however if they feel that is the only way forward, they can. When doing so they must:
- announce their intention as much in advance as they know it to
epel-announce, and their reasons for having to do this. 2) announce again when the package is in epel-testing.
How about a suggestion/recommendation (but _not_ requirement) that maintainers try to time incompatible upgrades approximately with RHEL point releases? So if you are going to update mediawiki (without a version in the package name) to a new version for EPEL 6, you try to do it about the same time that Red Hat releases the next 6.x version.
Red Hat releases public betas, so we generally know an update is coming (although not the exact timing); that would be the signal to "get your incompat upgrades into epel-testing".
For older releases (RHEL 5.x at this point for example), Red Hat slows down point releases, so waiting may not always be feasible for those.
I don't know about other admins, but I tend to pay more attention to release notes and such around that time (I know I should pay more attention all the time, but time is limited).
On Tue, 22 Jan 2013 10:10:24 -0600 Chris Adams cmadams@hiwaay.net wrote:
How about a suggestion/recommendation (but _not_ requirement) that maintainers try to time incompatible upgrades approximately with RHEL point releases? So if you are going to update mediawiki (without a version in the package name) to a new version for EPEL 6, you try to do it about the same time that Red Hat releases the next 6.x version.
Red Hat releases public betas, so we generally know an update is coming (although not the exact timing); that would be the signal to "get your incompat upgrades into epel-testing".
For older releases (RHEL 5.x at this point for example), Red Hat slows down point releases, so waiting may not always be feasible for those.
I don't know about other admins, but I tend to pay more attention to release notes and such around that time (I know I should pay more attention all the time, but time is limited).
Sure, sounds reasonable...
kevin
To add on to this, someone off list suggested to me that in addition to this we add to the workflow:
* When a rhel public beta happens we create a wiki page for: EPEL x Update y Technical notes * Maintainers are invited/encouraged to put any big changes in their packages planned to land after that release in the notes. * When RHEL X.Y comes out we meet up and maintainers ack their changes and/or note that they want to wait for centos/sl or wish to just defer. * We announce with the notes wiki page and push those updates at that point.
kevin
On Tue, 22 Jan 2013 23:52:40 +0100 Björn Persson bjorn@xn--rombobjrn-67a.se wrote:
Kevin Fenzi wrote:
- When a rhel public beta happens we create a wiki page for: EPEL x Update y Technical notes
And announce it on this list? Or is there a convenient way for non-customers to get notified when Red Hat releases a beta?
Well, there's
https://www.redhat.com/archives/rhelv6-beta-list/
which I think is a open list for anyone interested.
kevin
On Tue, Jan 22, 2013 at 11:52:40PM +0100, Björn Persson wrote:
- When a rhel public beta happens we create a wiki page for: EPEL x Update y Technical notes
And announce it on this list? Or is there a convenient way for non-customers to get notified when Red Hat releases a beta?
On Tue, Jan 22, 2013 at 5:52 PM, Björn Persson bjorn@xn--rombobjrn-67a.se wrote:
And announce it on this list? Or is there a convenient way for non-customers to get notified when Red Hat releases a beta?
Update ("Point Release") Beta and GA announcements are made on the _public_ Red Hat lists for EL5 and EL6. [1] [2] They are also made on the public, "low-traffic" Announce lists. [3] [4] In fact, Red Hat is quite notorious for cross-posting announcements (e.g., 6.4 Beta on the 5 list, etc...). I would assume most everyone here is already on them, at least the "Announce" lists. I regularly see community "EL Rebuild" discussions on those lists as well. Again, they are _public_ and I've never seen any moderation done on them regarding community "EL Rebuilds." In fact, they are hosted/serviced on exact same public hostname/mailman service [5] as this list, "epel-devel-list."
As far as "customer," anyone with any subscription, including a Red Hat "Developer" subscription, should have access to the Beta binary packages. Given the complementary ones handed out to EPEL maintainers, having one can never hurt to track any forthcoming RHEL changes. E.g., a dependency rebase or RFE/concurrent release upcoming in the next Update. Although you don't have to have a subscription to read the public "Technical Notes" for any Beta, including the breakdown of individual package updates, possible rebases/concurrent changes, etc.. (e.g., Section 4 for RHEL 6.4 Beta [6]). In fact, I see this workflow, based on Chris' original suggestion to handle changes more "discrete" on RHEL Updates ("Point Releases"), being the "EPEL equivalent" of the "Technical Notes" -- but with a 100% maintainer optional/opt-in (not required).
-- bjs
[1] Red Hat public RHEL5 list - https://www.redhat.com/mailman/listinfo/rhelv5-list
[2] Red Hat public RHEL6 list - https://www.redhat.com/mailman/listinfo/rhelv6-list
[3] Red Hat public RHEL5 Announce ("low traffic") list - https://www.redhat.com/archives/rhelv5-announce/
[4] Red Hat public RHEL6 Announce ("low traffic") list - https://www.redhat.com/archives/rhelv6-announce/
[5] Red Hat public lists (rhel-* lists, as well as epel-devel-list) - https://www.redhat.com/mailman/listinfo/
[6] Red Hat public docs: Enterprise Linux 6.4 Beta "Technical Notes" - https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6-Be...
-- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith ------------------------------------------------------------ American Libertarism died in the '70s with the invention of sensationalist US mass media. Two great casualties have been the NRA and Planned Parenthood; demonized by opposing media, all while ignoring their history and the 97% they really do.
Bryan J Smith wrote:
[3] Red Hat public RHEL5 Announce ("low traffic") list
[4] Red Hat public RHEL6 Announce ("low traffic") list
Those look like a good way to get notified, thanks.
Björn Persson
On 01/22/2013 09:50 PM, Kevin Fenzi wrote:
- When a rhel public beta happens we create a wiki page for: EPEL x Update y Technical notes
RHEL does not do public beta's for point releases. And RHEL-6 was the first time there was a public beta for a pre-release build tag'd 5.99.
- KB
On Tue, Jan 22, 2013 at 8:32 PM, Karanbir Singh mail-lists@karan.org wrote:
RHEL does not do public beta's for point releases. And RHEL-6 was the first time there was a public beta for a pre-release build tag'd 5.99.
OK, maybe not public. But the 6.4 beta is available from RHN as we speak. And RHEL entitlements are available (I think?) for EPEL maintainers. Me personally for my home use have https://www.redhat.com/apps/store/developers/rhel_developer_suite.html which gives access to the beta at https://rhn.redhat.com/network/software/channels/details.pxt?cid=10156
On Tue, Jan 22, 2013 at 10:18 PM, Jon Stanley jonstanley@gmail.com wrote:
OK, maybe not public. But the 6.4 beta is available from RHN as we speak.
Just to clarify ...
No, Update ("Point Release") Betas binaries are not public. Yes, Update ("Point Release") Betas announcements _are_ public.
See my prior e-mail regarding the public "rhel-*" lists, which are hosted on the same mailman server as this one, "epel-devel-list." ;)
-- bjs
On 22 January 2013 22:50, Kevin Fenzi kevin@scrye.com wrote:
To add on to this, someone off list suggested to me that in addition to this we add to the workflow:
- When a rhel public beta happens we create a wiki page for: EPEL x Update y Technical notes
- Maintainers are invited/encouraged to put any big changes in their packages planned to land after that release in the notes.
- When RHEL X.Y comes out we meet up and maintainers ack their changes and/or note that they want to wait for centos/sl or wish to just defer.
- We announce with the notes wiki page and push those updates at that point.
kevin
I personally really like it, I also have rhn accounts for testing new releases and I really like the option of introducing rebases in EPEL. Just my 2c.
Regards, --Simone
Can we let different version stay in the repo, but their package name is the same. I.e. collectd when user type yum install collectd, yum will notify user with version choice?
Users with 4.x can get 2 choice, 1st is 4.x.1, next is 5.x for example, and system will notify if users choose 2nd because of major version change.
Is it possible?
On Wed, Jan 23, 2013 at 8:04 AM, Christopher Meng cickumqt@gmail.com wrote:
Users with 4.x can get 2 choice, 1st is 4.x.1, next is 5.x for example, and system will notify if users choose 2nd because of major version change.
Is it possible?
Nope, the dependency resolver will automatically pick the higher NEVRA if the user types 'yum install collectd'
If there were two versions in the repo you could explicitly install *some* version, but you'd have to know the exact NEVRA that you want. This is how RHEL channels are structured - everything is there, you get the latest unless specifically asked otherwise (and a yum update would update you to the latest in any event).
epel-devel@lists.fedoraproject.org
-
Björn Persson -
Bryan Smith -
Chris Adams -
Christopher Meng -
Jon Stanley -
Karanbir Singh -
Kevin Fenzi -
Matthew Miller -
Simone Caronni