On Fri, 17 Jan 2014 08:00:58 -0500
Stephen Gallagher <sgallagh(a)redhat.com> wrote:
My thoughts are these (in no particular order).
* Treat this branch like Rawhide. All builds targeted at this are
composed to a repo. Signing is nice, but not mandatory in my opinion.
It's pretty much impossible to sign rawhide style repos. ;)
* When rhel7.1 comes out, there is no automatic movement from
epel7-pending into the epel branch. We open a merge window where
packages are allowed to merge from the epel7-pending git branch.
Merging a major upgrade outside this window is forbidden. At this
time, any packager that believes their package is ready for prime-time
may manually perform a merge, build and submission to Bodhi.
ok. How long does the merge window last? Can people push to stable
during this? Or everything stays in testing until the window closes?
I think we could set a policy of "merge window opens one week
official RHEL release and remains open for two/three weeks after
that". Packages have to go through Bodhi approval for upgrade (perhaps
we mandate at least one positive karma review on major upgrades?)
which may take longer than the merge window, but they have to be
submitted within that time.
This leaves people using enterprise linux rebuilds in a bad place since
they don't have the new release to test with. Only once they have
upgraded would they be able to be sure the packages are good for the
This also means that many folks will delay the update on many of their
machines (7.0->7.1) until the window is over and they can update epel
stuff at the same time. Otherwise they have to schedule 2 big updates
(the 7.0->7.1 and the epel merge window closing).
The majority isn't necessarily as interesting as the popular
Well, it's like anything else... "I don't care about any packages
except this specific ones that I really really care about" :)
There are plenty of people out there who want to see new Django,
Wordpress, Trac, etc. packages that we simply cannot cleanly upgrade
in EPEL 6 today because they aren't fully backwards-compatible.
Well, Django is a interesting one... whats wrong with the forward
compat packages there?
<wait until your apps all are able to work with 1.5>
Update to Django15 and do the incompatible update
lather, rinse, repeat.
I know, the pain there is the packaging...
COPRs is really a workaround for (IMHO) a failure of policy in EPEL
remain useful as the world moves ahead. It's pretty unrealistic to
expect volunteer package maintainers to support their packages for the
same duration that Red Hat supports RHEL (currently ten years for RHEL
5 and 6). I think we're discouraging community inclusion if we don't
offer people a policy that allows them to keep their package closer to
upstream for reduced maintenance effort.
Well, I think lots of people do find EPEL useful. I know I do.
It's a balancing act. Lots of different groups want different things.
Additionally, it's hard to say what most EPEL consumers want because
they aren't very vocal, they just consume. ;)
What about Toshios ideas of allowing conflicts:
We add a EPEL specific guideline that allows forward compat packages to
NOT be parallel installable, as long as they conflict with the other
versions of that package. Would that get us to a better place?
That reduces the problems with making parallel installable compat
packages, you simply need to adjust the names and pass review.