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
signature.asc
Description: PGP signature
_______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
