<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 13 August 2014 06:28, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 13 Aug 2014 01:25:04 +0200<br>
<div class="">Stephen John Smoogen <<a href="mailto:smooge@gmail.com">smooge@gmail.com</a>> wrote:<br>
<br>
> On 12 August 2014 21:56, Dennis Gilmore <<a href="mailto:dennis@ausil.us">dennis@ausil.us</a>> wrote:<br><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<br>
> > > changes.<br>
</div>What is the problem you're trying to solve here?<br>
<div class=""><br></div></blockquote><div><br></div><div>The problem I am trying to solve is that we have packages that require large deltas to stay patched and relevant to users. However users do not want to have these appearing 'randomly' during a release cycle. So by keying such large deltas to the Red Hat point releases we have a place where the updates can occur and if old stuff is still wanted with new stuff how to maintain both.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> > > * Archive 7.0. The toplevel 7 tree is a symlink to whatever<br>
> > > point 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<br>
> > > around the 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>
</div>It doesn't actually give us any extra arches. I would like to work out<br>
a way to enable EPEL contribution via a CentOS path and have EPEL be<br>
part of both Fedora and CentOS.<br>
<div class=""><br></div></blockquote><div><br></div><div>if CentOS gets ARM32 and i386 then it would add 2 arches that people are 'wanting' but RHEL does not support.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
> > > * Could we do an ISV program like quaid does?<br>
> ><br>
> > something to consider is moving epel to /opt/fedora/epel or<br>
> > somewhere like it, then dealing with overlap etc should be simpler,<br>
> > but it would take a massive change in packaging and could really<br>
> > only be done in epel8<br>
> ><br>
><br>
> I think that would be something with <a href="http://softwarecollections.org" target="_blank">softwarecollections.org</a> as that<br>
> seems in line with their way of packaging items. I think that for<br>
> some sorts of packages and libraries it makes sense for that, but I<br>
> don't know if EPEL would mix and match like that. What I would like<br>
> to do is the following:<br>
<br>
</div>I disagree. FHS says that anything not part of the OS should go<br>
in /opt/ EPEL is an add on and not part of the OS.<br>
<div><div class="h5"><br></div></div></blockquote><div><br></div><div>In the past we did not do this because we were bound by the Fedora Packaging Rules. I don't have the energy or want to try and fight that Windmill but I am not going to stand in someone who wants to.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
> We move from our moving distribution to a point release cycle with a<br>
> disk layout like the following:<br>
><br>
> epel<br>
> epel/development/<br>
> epel/development/5<br>
> epel/development/6<br>
> epel/development/7<br>
> epel/beta/5.12<br>
> epel/beta/6.7<br>
> epel/beta/7.1<br>
> epel/releases<br>
> epel/releases/6.6<br>
> epel/releases/5.11<br>
> epel/releases/7.0<br>
> epel/updates<br>
> epel/updates/6.6<br>
> epel/updates/5.11<br>
> epel/updates/7.0<br>
> epel/updates/testing/<br>
> epel/updates/testing/6.6<br>
> epel/updates/testing/5.11<br>
> epel/updates/testing/7.0<br>
><br>
> epel/development would be like the current EPEL directories but<br>
> without the stringent requirements that packages are locked to a<br>
> specific version for the lifetime of the overall RHEL release.<br>
> Instead whenever RHEL releases a new dot release (7.0, 6.6, 5.11),<br>
> EPEL would branch off the releases from development to beta/7.0 or<br>
> beta/6.6 etc. Packages would be built against the point release and<br>
> would need to be tested to get sufficient karma for 'release'. Once 6<br>
> weeks have passed from the RHEL point release, all packages which had<br>
> gotten enough karma and that had completed repository trees would be<br>
> put into epel/releases/6.6. Updates to that package would be put into<br>
> updates/testing/6.6 and then promoted to updates/6.6 when enough<br>
> karma had been given for an update. New packages which were added<br>
> after the point release would show up in updates following the<br>
> process Fedora does for new packages between point releases.<br>
<br>
</div></div>This will make a much larger work load for releng. what extra resources<br>
will we have? I find it quite confusing. I honestly do not like the<br></blockquote><div><br></div><div>What extra resources do you need? I am sorry it is confusing.. I am trying to communicate it while severely jetlagged. Part of this is to get a conversation going so that we can find out why this would not work or would work.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
idea of having a static snapshot for releases. we have a few options<br>
available to make older versions available. we can mash the tree with<br>
every package ever released. or we can work on fixing the patches in<br>
mash to have say the last 2 or 3 builds. I think we are better off<br>
having epel as somthing stable where you can not put incompatible<br>
changes for the life of the rhel release and epel-extras where things<br>
are able to change quickly and in incompatible ways.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>That was an alternative but I wasn't sure how much koji/bodhi/pkg changes it would require or what packages would actually stay in EPEL versus EPEL-extras as most packages have had to require a major change over a 10+ year lifetime that RHEL is going to. </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">Dennis<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Stephen J Smoogen.<br><br></div>
</div></div>