<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 12 August 2014 21:56, Dennis Gilmore <span dir="ltr"><<a href="mailto:dennis@ausil.us" target="_blank">dennis@ausil.us</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Tue, 12 Aug 2014 21:05:07 +0200<br>
Stephen John Smoogen <<a href="mailto:smooge@gmail.com">smooge@gmail.com</a>> wrote:<br>
<br><br>
> Where are we now:<br>
> We support 3 arches.<br>
</div></div>I think you mean 3 releases. we have 3 arches for epel5 and epel6 and 2<br>
for epel7<br>
<div class=""><br></div></blockquote><div><br></div><div>I actually meant arches as I forgot that i386 isn't a 7 item.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">
> RHEL4: 1258 srpms. EOL<br>
> RHEL5: 3651 srpms<br>
> RHEL6: 5449 srpms<br>
> RHEL7: 3100 srpms and growing fastest<br>
><br></div><div><div class="h5">
> * Maybe as the way to implement EPIC rather than EPEL.<br>
> * Policy change that allows for regular major changes in EPEL.<br>
> * Can't update at any times.<br>
> * Can make incompatible changes on the next point release of<br>
> RHEL->CentOS.<br>
> * Example: When RHEL7.1 comes out we have a 30 day window to get<br>
> packages updated and new packages in that make incompatible changes.<br>
> * Archive 7.0. The toplevel 7 tree is a symlink to whatever point<br>
> release is latest.<br>
> * Formalize the governance of EPEL.<br>
> * Written policies of some sort for decision making<br>
> * Elections?<br>
> * Problems to solve:<br>
> * Don't want to just listen to the people who are loudest<br>
> * Don't want to just listen to the people who have been around the<br>
> longest<br>
> * Do we want automated testing of EPEL? yes. get it working on<br>
> whatever subset you can and we'll go on from there.<br>
> * Move to CentOS as build system? Gives us additional arches.<br>
><br>
> * Could we do an ISV program like quaid does?<br>
<br>
</div></div>something to consider is moving epel to /opt/fedora/epel or somewhere<br>
like it, then dealing with overlap etc should be simpler, but it would<br>
take a massive change in packaging and could really only be done in<br>
epel8<br></blockquote><div><br></div><div>I think that would be something with <a href="http://softwarecollections.org">softwarecollections.org</a> as that seems in line with their way of packaging items. I think that for some sorts of packages and libraries it makes sense for that, but I don't know if EPEL would mix and match like that. What I would like to do is the following:</div>
<div><br></div><div>We move from our moving distribution to a point release cycle with a disk layout like the following:</div><div><br></div><div>epel</div><div><div>epel/development/</div><div>epel/development/5</div><div>
epel/development/6</div><div>epel/development/7</div><div>epel/beta/5.12</div><div>epel/beta/6.7</div><div>epel/beta/7.1</div><div>epel/releases<br></div></div><div>epel/releases/6.6</div><div>epel/releases/5.11</div><div>
epel/releases/7.0</div><div>epel/updates</div><div>epel/updates/6.6</div><div>epel/updates/5.11</div><div>epel/updates/7.0</div><div>epel/updates/testing/</div><div>epel/updates/testing/6.6</div><div>epel/updates/testing/5.11</div>
<div>epel/updates/testing/7.0</div><div><br></div><div>epel/development would be like the current EPEL directories but without the stringent requirements that packages are locked to a specific version for the lifetime of the overall RHEL release. Instead whenever RHEL releases a new dot release (7.0, 6.6, 5.11), EPEL would branch off the releases from development to beta/7.0 or beta/6.6 etc. Packages would be built against the point release and would need to be tested to get sufficient karma for 'release'. Once 6 weeks have passed from the RHEL point release, all packages which had gotten enough karma and that had completed repository trees would be put into epel/releases/6.6. Updates to that package would be put into updates/testing/6.6 and then promoted to updates/6.6 when enough karma had been given for an update. New packages which were added after the point release would show up in updates following the process Fedora does for new packages between point releases. </div>
<div><br></div><div>Later when 7.1, 6.7, 5.12 (or whatever they are called) comes out then the process is repeated which will make sure that packages that aren't needed enough to have sponsors will not be in EPEL and potentially broken and large updates are possible so if python34 is in 7.0 but python35 is ready for 7.2 it can replace it without problems (or similarly with ruby23 etc etc). Once the next point release is made ready, the old point release will be archived off to keep storage levels within reason. </div>
<div><br></div><div>I know that this proposal needs a lot more fleshing out, but I think it covers the use cases many users of EPEL need for long term usage of packages.</div></div><br clear="all"><div><br></div>-- <br><div dir="ltr">
Stephen J Smoogen.<br><br></div>
</div></div>