<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Hi,</div><div><br></div><div>The EPEL meeting later today (Friday 16:00 UTC) will discuss</div><div>EPEL.next again (EPIC). I would attend but it is rather late</div><div>for me (1am in Japan), is it possible someone from the WG</div><div>could attend on our behalf to help get our ideas/concerns/input also</div><div>included <span style="font-size: 12pt;">in the discussion.</span></div><div><br></div><div>It seems from the previous (first) meeting [1] last week that they</div><div>are currently leaning towards (one or more) faster moving rolling-release repos.</div><div>This will certainly be an improvement but I feel it is not flexible</div><div>enough to provide long-term support for multiple versions of stacks.</div><div><br></div><div>eg I would certainly like to make multiple versions of <span style="font-size: 12pt;">Haskell ghc </span><span style="font-size: 12pt;">available</span></div><div><span style="font-size: 12pt;">for EPEL/EPIC over the whole life-time, </span><span style="font-size: 12pt;">even though </span><span style="font-size: 12pt;">perhaps only</span></div><div><span style="font-size: 12pt;">the EPEL and latest EPIC branch would see </span><span style="font-size: 12pt;">continuing maintenance and updates.</span></div><div>Rolling release seems to be the exact weakness of EPEL so replicating</div><div>that in EPIC seems like a bad idea to me.</div><div><br></div><div>A counter-point might be that branches is too much work</div><div>but really it is no different from Fedora branches, which also become EOL.</div><div><br></div><div>Jens</div><div><br></div><div>[1] http://meetbot.fedoraproject.org/epel/2014-08-22/epel_reboot.2014-08-22-16.00.html</div></div></body></html>