On Fri, 29 Aug 2014 03:45:12 -0400 (EDT)
Jens Petersen <petersen(a)redhat.com> wrote:
I read the log from last weeks EPEL meeting .
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
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?