>> Well, it means the ones in now are the ones we will try and stick with >> for the next 7 years. ;) >> <snip>
I think the 7 year plan is a bit difficult for most maintainers. I love the idea of minimal breakage though. We need to remind users to subscribe to epel-announce because from time to time, there will be breakage, whether it's due to dead upstream, security fixes or something else, it will happen. It sucks, and we try to avoid it, but minimal does not mean zero. As for releasing EPEL6 and when, I'd like to wait a bit more. I love not having to override buildroots right now for builds and deps. Also, we can't run repoclosure until CentOS is out, at least the way it is currently being done for EPEL4/5. Keep in mind that while 6 has been released, many organizations will put it in a lab, and play with it for months before really hitting it hard and in production. I know my company probably won't have large-scale production applications on 6 for at least a year. I'm sure other shops are faster, but if you want to jump on a stable enterprise product as fast as possible, then I assume you have the means to build up your needed catalog of RPMS and management software. I'm not saying we should wait a year for EPEL6 to be considered ready to go, but 60 days might not be too much. Just my 2 cents, stahnma _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
