On Sep 04 18:20, Stephen John Smoogen wrote: > So this is my general proposal for per point release. > > > Problem trying to be solved: > > EPEL's original goal around a 5-7 year product has run into issues where > various packages end up having shorter lifetimes than can be maintained in > that period. What happens is that the upstream is changing the code too > massively for any sort of 'back-port' to be possible. Some software can be > 'patched' around by making it parallel installable but others (say puppet) > only work if there is only one version not just on the system but > throughout an entire ecosystem of systems (thus if you update one, they all > have to be updated to the same version.) While EPEL has a process of saying > you can announce a major change it is severely frowned on and usually ends > up with various users asking 'can you just keep the older version around a > bit longer...' ad infinitum. Another problem is that it isn't clear how > much notice is needed for a change to be made or what changes are being > made so that users and package owners end up confused and upset with each > other. > > Possible solution: > > Make it so that updates to these sorts of packages occur at regular > intervals. There are three cycles these could occur: regular date driven > (July 1st of every year for example), the Fedora release cycle (Fedora 22 > has been released, you can update now), and the Red Hat Enterprise release > cycle (RHEL-6.6 is out, you can release now). Each of these cycles has > their bonuses and minuses but I think that connecting to the RHEL cycle > will be more in line with what downstream users of EPEL are going to be > more in sync with. > > Proposed implementation: > > Every Red Hat Enterprise Dot Release has a beta period and then a release > period. After the release period there is a couple of weeks until a CentOS > release is available. Since only the betas and CentOS release are generally > available to any person off the street I am looking at those being 'action > points' where the dot release period would be done. When a RHEL beta dot > release (example RHEL-6.6 beta) is announced, EPEL.dot would say that > packages to be updated in the next release are going to be accepted into > EPEL-dot-testing. Package owners who are needing or wanting to make major > changes in their EPEL package sets would target builds to that channel. > People can test as needed or at least be aware where they could have > tested. Sometime after the next dot release, CentOS releases their latest > 'this is the state of CentOS build' which anyone needing to test latest > builds can get. This acts as a marker for when EPEL.dot will 'release' its > next tree which would be 1 month after the CentOS GA. During that time, > everything is rebuilt against the latest RHEL (to find any FTBS or ooops > they dropped libmuffin and I needed it) and at the end of the month > EPEL-6.7 is put out and EPEL-6.6 is set to be sent to archives after an > appropriate time. Like CentOS, EPEL-6 -> EPEL-6.6 and then EPEL-6.7. > > In the case of last planned release (RHEL-5.12?), a different mechanism > could be used for when updates occur if there is enough people willing to > do the work. Otherwise packages go into that tree until EPEL ends building > for it. > > Note only one tree is being built against. If someone wants to 'keep' > EPEL-6.5 running, they can grab the src.rpms from archives and do it > themselves on their own hardware.. EPEL only deals with RHEL current. > > Have I made this clearer or muddier? > > > -- > Stephen J Smoogen.
I think this fits in well with the release calendar(s) that EPEL consumers are already working with. Not sure what other feedback I can give, except that I like it. Brian -- Brian Stinson bstin...@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
