Fudcon EPEL discussion summary/report

[Kevin Fenzi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20130122/ca76098b/attachment.sig>