On Tue, May 4, 2010 at 8:45 AM, Jesse Keating <jkeating@xxxxxxxxxx> wrote: > So I'd love to have multi-level policy, but in my opinion it should get > harder and harder to push an update as the release gets older, not > easier. In general I'm in agreement with this. But at the same time I'm concerned that the policy is going to make it more difficult for me to respond to breakage in my packages created when a maintainer does an update (mistakenly) that one of my packages depend on. Not to harp on any of my peers...so apologizes if to anyone I think I'm picking on in the following case study. I just went through a round of breakage associated with matplotlib and numpy caused by other maintainer action in both rawhide and EPEL. In rawhide it was really easy for me to get fixes out. For EPEL, because of the update policy..it was harder for me...the maintainer who is trying to react to brokenness created by another maintainer. The thing I really need help with as a maintainer is help seeing when a update in testing is a potential impactor for one of the packages I maintain. So I can get ahead of any problems and do the testing I need to do against the update in updates-testing and keep it from hitting stable until I can spin up versions of my packages that work with the update. I don't want to be in a position where I have to react to breakage. I want to be proactive, but I really need a better heads up as to when things that impact my packages are in the que for stable so I can better prioritize my time. -jef -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
