<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">&lt;<a href="mailto:sgallagh@redhat.com" target="_blank">sgallagh@redhat.com</a>&gt;</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>
&gt; On Wed, 15 Jan 2014 10:32:18 -0500 Stephen Gallagher<br>
&gt; &lt;<a href="mailto:sgallagh@redhat.com">sgallagh@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Perhaps this would be a good time to reopen the conversation of<br>
&gt;&gt; minor-release policy changes?<br>
&gt;<br>
&gt; Sure.<br>
&gt;<br>
&gt;&gt; RHEL releases approximately every six months with a minor<br>
&gt;&gt; release. It seems fair to allow major EPEL upgrades to occur in<br>
&gt;&gt; sync with those releases as well.<br>
&gt;&gt;<br>
&gt;&gt; So my suggestion would be that EPEL should have two branches for<br>
&gt;&gt; EPEL 7: the epel7 branch and the epel7-pending branch. The idea<br>
&gt;&gt; of this second branch would be sort of an EPEL Rawhide, where<br>
&gt;&gt; major upgrades can be staged. Then, when RHEL releases a minor<br>
&gt;&gt; update (such as RHEL 7.1), we have a (one-month?) integration<br>
&gt;&gt; period where we ensure that packages in epel7-pending work on the<br>
&gt;&gt; newest minor release and then they are merged back to epel7. If<br>
&gt;&gt; they miss this merge window, they have to wait until the next<br>
&gt;&gt; minor release.<br>
&gt;&gt;<br>
&gt;&gt; This allows us a regular, planned ability to move to newer EPEL<br>
&gt;&gt; packages, without destabilizing EPEL in general.<br>
&gt;<br>
&gt; ok, issues/thoughts:<br>
&gt;<br>
&gt; * Another branch is a fair bit more work rel-eng and infra wise.<br>
&gt; Would they be completely seperate? How do we merge them at a update<br>
&gt; point?<br>
&gt;<br>
&gt; ie, say I have foo. I have 1.0 in epel7 and push 1.2 to<br>
&gt; epel7-pending. Does the epel7-pending one use bodhi? Does it get<br>
&gt; signed and composed and push to a repo somewhere? now, say rhel7.1<br>
&gt; comes out. How do we reconcile the two branches/trees/composes?<br>
&gt;<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>
&gt; * The change point seems like it would be kinda fluid, which would<br>
&gt; not be great expectation wise. Ie, say rhel7.1 comes out. How long<br>
&gt; after that do we wait to push the changes? We can&#39;t really do it<br>
&gt; the same time, as we won&#39;t know for sure what that will be. We<br>
&gt; could do it as soon as it&#39;s public, but then enterprise rebuilds<br>
&gt; aren&#39;t ready yet. We could wait for CentOS, but then do we wait for<br>
&gt; SL? OEL? Do we tell users &quot;it can happen some random time after a<br>
&gt; minor release, please pay attention&quot;?<br>
&gt;<br>
<br>
</div>I think we could set a policy of &quot;merge window opens one week after<br>
official RHEL release and remains open for two/three weeks after<br>
that&quot;. 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>
&gt; * The majority of epel packages I think don&#39;t care about this.<br>
&gt; It&#39;s only a subset. Perhaps we could do something with them? Move<br>
&gt; them to coprs, get them in as CentOS variants, something?<br>
&gt;<br>
<br>
</div>The majority isn&#39;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&#39;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&#39;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&#39;re discouraging community inclusion if we don&#39;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&#39;t changing every 6 months to a year. Like Toshio mentioned before, existing projects want what&#39;s there to stay there and new projects want the latest and greatest. The EL mentality is &quot;stable and predictable&quot; and the Fedora mentality is &quot;latest and greatest&quot;, so I think that both options are there for those that want them and I don&#39;t think that changing EL to be more Fedora like is a good thing.<br>
</div></div>