On Thu, May 30, 2019 at 4:02 PM Troy Dawson <tdawson(a)redhat.com> wrote:
On Thu, May 30, 2019 at 12:18 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
> Also might there be people who want to always keep something in
rawhide
> and never push it to the stable stream? Or do we want to encourage only
> things destined for the next minor change land in epel8-rawhide?
>
Yes. We need to keep that in consideration.
When cleaning up the -testing branches of EPEL6 and EPEL7 we found
there were people who had versions in -testing that they never
intended to push to stable.
Once EPEL8/7 has modularity, there will be an official way to do that,
but until that happens, we need to assume that some people will use
rawhide as a way to have a second version of their package.
Right, I think Troy has the pulse of it. I think the current design is
compatible with that, though. I see the following common cases from
most to least common:
1) Leave package.cfg in epel8, build only there -> epel8 repo and
epel8-rawhide repo
2) Remove package.cfg in epel 8. Build stable in epel8 -> epel8 repo.
Build major release planned for an upcoming (not necessarily next...)
X.Y release in Rawhide -> epel8-rawhide repo.
3) Remove package.cfg in epel 8. Build stable in epel8 -> epel8 repo.
Build rolling release in epel8-rawhide of the latest upstream bits,
not necessarily ever planning to move it into stable -> epel8-rawhide
repo.
Case 3 I think will slowly disappear once we enable (and simplify
creation of) modules in EPEL 8, since they'll be able to just provide
a non-default stream.