EPEL Python 3 for 7?

[Kevin Fenzi]

On Wed, 15 Jan 2014 10:32:18 -0500
Stephen Gallagher <sgallagh at redhat.com> wrote:

> Perhaps this would be a good time to reopen the conversation of
> minor-release policy changes?

Sure. 

> RHEL releases approximately every six months with a minor release. It
> seems fair to allow major EPEL upgrades to occur in sync with those
> releases as well.
> 
> So my suggestion would be that EPEL should have two branches for EPEL
> 7: the epel7 branch and the epel7-pending branch. The idea of this
> second branch would be sort of an EPEL Rawhide, where major upgrades
> can be staged. Then, when RHEL releases a minor update (such as RHEL
> 7.1), we have a (one-month?) integration period where we ensure that
> packages in epel7-pending work on the newest minor release and then
> they are merged back to epel7. If they miss this merge window, they
> have to wait until the next minor release.
> 
> This allows us a regular, planned ability to move to newer EPEL
> packages, without destabilizing EPEL in general.

ok, issues/thoughts: 

* Another branch is a fair bit more work rel-eng and infra wise. Would
  they be completely seperate? How do we merge them at a update point? 

ie, say I have foo. I have 1.0 in epel7 and push 1.2 to epel7-pending. 
Does the epel7-pending one use bodhi?
Does it get signed and composed and push to a repo somewhere?
now, say rhel7.1 comes out. How do we reconcile the two
branches/trees/composes?

* The change point seems like it would be kinda fluid, which would not
  be great expectation wise. Ie, say rhel7.1 comes out. How long after
  that do we wait to push the changes? We can't really do it the same
  time, as we won't know for sure what that will be. We could do it as
  soon as it's public, but then enterprise rebuilds aren't ready yet.
  We could wait for CentOS, but then do we wait for SL? OEL? Do we
  tell users "it can happen some random time after a minor release,
  please pay attention"?

* The majority of epel packages I think don't care about this. It's
  only a subset. Perhaps we could do something with them? Move them to
  coprs, get them in as CentOS variants, something?
 
> In order to not make this a willy-nilly breakage every six months, we
> might want to set some limits (or at least guidelines) on what is or
> is not allowed to upgrade at the minor release. But I'd be fine with
> deferring making such decisions until we have a demonstrated need
> (i.e. fix it only if packages/EPEL is actually breaking).

Sure, agreed. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20140116/219a87a8/attachment.sig>