On 11/19/2011 10:53 PM, Greg Lindahl wrote: > On Sat, Nov 19, 2011 at 09:23:09PM +0000, Karanbir Singh wrote: >> On 11/18/2011 07:58 PM, Greg Lindahl wrote: >>> Upstream has never tested the combination of packages available in CR. >> >> if you look at the rhn experience for most people - its actually quite >> in line with the CR/ process - as if it were just one release moving >> along with point-in-time install media being made available. Otoh, its >> been a long time since i did anything with rhn, have things changed ? > > Well, my experience (and I think this is fairly typical) is that I > install all the updates soon after they arrive. So there's no way I > could end up with a 6.0+6.0updates with a single 6.1 package, which is > what CR is intended to do. > Not sure where you got that. CR is intended to add many packages and distribute them more evenly throughout the point release creation process in a stage way. Where the media set is not yet done for the future point release, but all the RPMs are in CR. It allows us to prioritize building (get enough "dependencies" done and get the security updates out in the first batch and release them to CR ... then build all the other RPMs in the point release. We can also build the updates for the next point release (some of the zero day ... also many Firefox, etc. come out) while we are still putting together the final point release media set. It seems to me that you are arguing for a process that puts out staged sets of updates and then saying CR is bad (which is how we can do staged updates). > During the 5.X series, there was one time that I downgraded a package, > expat, due to a bug that took Upstream a long time to fix. One. > >> Also, keep in mind that people can opt out of the process and lock their >> machines into a point release ( eg. lock into 6.1, and only move to 6.2 >> when they want to ). > > Yes, of course, that's what I plan on doing. > > Les Mikesell brings up the reasonable question of whether version > dependencies might save the day. They probably will in most cases, but > with both Gentoo and Debian, I have discovered enough errors in those > dependencies that I don't expect Upstream to get this right, > especially when almost all of their users aren't going to try to > install a single 6.1 package on 6.0. I doubt I'll convice Les with > this argument, but there you have it. As an Enterprise user, I'm not > interested in experimenting with having most CentOS users do something > that few Upstream users do. Baaaaah. Baaaaaah (baaaad sheep imitation.) Again ... not sure what you think CR is. CR is basically dumping all updates as we get them built and working into a repo that people can install in real time, instead of waiting a month (oe more) for every single update to complete before we release anything (our current practice). I am really failing to see how that is what you are talking about at all ... maybe I am lost. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20111120/f7337506/attachment-0007.sig>