On Fri, 29 Aug 2014 03:45:12 -0400 (EDT) Jens Petersen petersen@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