EPEL EPIC minor release branches

[Kevin Fenzi]

On Fri, 29 Aug 2014 03:45:12 -0400 (EDT)
Jens Petersen <petersen at redhat.com> wrote:

> Hi,
> 
> I read the log from last weeks EPEL meeting [1].
> It is great to see discuss happening on (codename:) EPIC. :-)
> 
> At Flock at the EPEL.next session there was mention of using
> branches/tags per minor EL version for EPIC for greater long term
> flexibility, which I thought sounded pretty attractive: it would
> allow people to switch to a newer version of EPIC when they are ready
> rather either being stuck on EPEL or forced to upgrade to the latest
> greatest immediately.
> 
> Granted there are questions around how (long) to maintain
> the older release branches, but I think this can be handled
> by EOL policy similar to what we have for Fedora.
> 
> I think having EPIC not just be a rolling release would
> be a big advantage over EPEL and it would fit with the
> release model that is already working well for RHEL/Centos et al.
> I feel EPEL/EPIC is too long lived not to have branches. :)
> 
> I would have liked to have join the meeting tonight to discuss
> but it is at 1am in my timezone unfortunately...

Can you expand on your proposed scheme?

we have a epic-7.0 and then when rhel7.1 is released, we make a
epic-7.1 branch and keep 7.0 around?

Would 7.0 still need to build against rhel 7.0 ? This would be a big
pain, as it would mean we would need to keep repos of every minor
release available for koji. 

How long would it stay around?

When epic-7.1 was created, would it start as a empty repo and require
builds to populate it? or would it somehow copy from 7.0 ?

When epic-7.1 is created, what packages would have branches in it? How
would we add new ones? 

Would each of these minor branches use bodhi? 

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