On Thu, 4 Sep 2014 18:20:19 -0600 Stephen John Smoogen <smo...@gmail.com> 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. ok, so to be clear this is a change in the existing EPEL repo(s)? Or is this new seperate repos? > 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. The problem with that IMHO is that a month after people have updated, they have forgotten about this, and get surprised when a chud of incompatible changes land. ;( If this is a seperate repo they opt into, we could try and manage expectations for that tho. > 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? Some clearer. :) kevin
signature.asc
Description: PGP signature
_______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel