On Tue, 2010-05-04 at 09:07 -0800, Jeff Spaleta wrote: > 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 If the breakage was in the form of broken deps, the original update would not have been allowed out in the first place. The maintainer would have had to contact all the folks with packages that would break and get them to coordinate the update. If the breakage was more of a functional break and not a dep break, that's where automated testing comes in, and we grow the automated functional testing of updates so that if an update comes along we can detect the breakage and alert both parties. The solution to "shit went out and broke my stuff" isn't to make it easier to put shit out, it's to make it harder to put /broken/ shit out in the first place. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
