<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 17, 2014 at 6:00 AM, Stephen Gallagher <span dir="ltr"><<a href="mailto:sgallagh@redhat.com" target="_blank">sgallagh@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div><div><div class="h5">On 01/16/2014 10:14 AM, Kevin Fenzi wrote:<br>
> On Wed, 15 Jan 2014 10:32:18 -0500 Stephen Gallagher<br>
> <<a href="mailto:sgallagh@redhat.com">sgallagh@redhat.com</a>> wrote:<br>
><br>
>> Perhaps this would be a good time to reopen the conversation of<br>
>> minor-release policy changes?<br>
><br>
> Sure.<br>
><br>
>> RHEL releases approximately every six months with a minor<br>
>> release. It seems fair to allow major EPEL upgrades to occur in<br>
>> sync with those releases as well.<br>
>><br>
>> So my suggestion would be that EPEL should have two branches for<br>
>> EPEL 7: the epel7 branch and the epel7-pending branch. The idea<br>
>> of this second branch would be sort of an EPEL Rawhide, where<br>
>> major upgrades can be staged. Then, when RHEL releases a minor<br>
>> update (such as RHEL 7.1), we have a (one-month?) integration<br>
>> period where we ensure that packages in epel7-pending work on the<br>
>> newest minor release and then they are merged back to epel7. If<br>
>> they miss this merge window, they have to wait until the next<br>
>> minor release.<br>
>><br>
>> This allows us a regular, planned ability to move to newer EPEL<br>
>> packages, without destabilizing EPEL in general.<br>
><br>
> ok, issues/thoughts:<br>
><br>
> * Another branch is a fair bit more work rel-eng and infra wise.<br>
> Would they be completely seperate? How do we merge them at a update<br>
> point?<br>
><br>
> ie, say I have foo. I have 1.0 in epel7 and push 1.2 to<br>
> epel7-pending. Does the epel7-pending one use bodhi? Does it get<br>
> signed and composed and push to a repo somewhere? now, say rhel7.1<br>
> comes out. How do we reconcile the two branches/trees/composes?<br>
><br>
<br>
</div></div>My thoughts are these (in no particular order).<br>
* Treat this branch like Rawhide. All builds targeted at this are<br>
composed to a repo. Signing is nice, but not mandatory in my opinion.<br>
* When rhel7.1 comes out, there is no automatic movement from<br>
epel7-pending into the epel branch. We open a merge window where<br>
packages are allowed to merge from the epel7-pending git branch.<br>
Merging a major upgrade outside this window is forbidden. At this<br>
time, any packager that believes their package is ready for prime-time<br>
may manually perform a merge, build and submission to Bodhi.<br>
<div class="im"><br>
<br>
> * The change point seems like it would be kinda fluid, which would<br>
> not be great expectation wise. Ie, say rhel7.1 comes out. How long<br>
> after that do we wait to push the changes? We can't really do it<br>
> the same time, as we won't know for sure what that will be. We<br>
> could do it as soon as it's public, but then enterprise rebuilds<br>
> aren't ready yet. We could wait for CentOS, but then do we wait for<br>
> SL? OEL? Do we tell users "it can happen some random time after a<br>
> minor release, please pay attention"?<br>
><br>
<br>
</div>I think we could set a policy of "merge window opens one week after<br>
official RHEL release and remains open for two/three weeks after<br>
that". Packages have to go through Bodhi approval for upgrade (perhaps<br>
we mandate at least one positive karma review on major upgrades?)<br>
which may take longer than the merge window, but they have to be<br>
submitted within that time.<br>
<div class="im"><br>
<br>
> * The majority of epel packages I think don't care about this.<br>
> It's only a subset. Perhaps we could do something with them? Move<br>
> them to coprs, get them in as CentOS variants, something?<br>
><br>
<br>
</div>The majority isn't necessarily as interesting as the popular packages.<br>
There are plenty of people out there who want to see new Django,<br>
Wordpress, Trac, etc. packages that we simply cannot cleanly upgrade<br>
in EPEL 6 today because they aren't fully backwards-compatible.<br>
<br>
COPRs is really a workaround for (IMHO) a failure of policy in EPEL to<br>
remain useful as the world moves ahead. It's pretty unrealistic to<br>
expect volunteer package maintainers to support their packages for the<br>
same duration that Red Hat supports RHEL (currently ten years for RHEL<br>
5 and 6). I think we're discouraging community inclusion if we don't<br>
offer people a policy that allows them to keep their package closer to<br>
upstream for reduced maintenance effort.<br></blockquote></div><br></div><div class="gmail_extra">Yes, this makes the experience better for maintainers, but makes the experience worse for users and developers of existing tools/infrastructure. All the RHEL users I know choose it because they want a stable platform that isn't changing every 6 months to a year. Like Toshio mentioned before, existing projects want what's there to stay there and new projects want the latest and greatest. The EL mentality is "stable and predictable" and the Fedora mentality is "latest and greatest", so I think that both options are there for those that want them and I don't think that changing EL to be more Fedora like is a good thing.<br>
</div></div>