On Friday, May 08 2009, Mark McLoughlin said: > On Thu, 2009-05-07 at 13:56 -0700, Jesse Keating wrote: > > The freeze override process exists to add a filter between developer and > > repo to catch the obvious and to help maintainers think a moment about > > what they're doing and whether it's acceptable to do in a freeze period. > > I think this works well. It forces one briefly explain the benefit, and > justify the risk, of the update. That alone makes it less likely you're > going to screw things up with a hugely risky, or low value, update. > > I'd still like to make the process a little more visible, though. These > freeze break requests are fairly central to the development process in > the lead up to GA. It should be easier for folks to follow what's going > on than running a trac query. > > > it would make a lot more sense if developers would treat updates to a > > release with the same care as they treat updates during a freeze period, > > but that's a fight for another day. > > Agreed. It seems logical that post-GA updates would go through a similar > process. > > It could be as simple as two new fields in bodhi - "Benefit to users" > and "Risk of regressions" - and the ability for folks to jump in and say > "wait, that doesn't make sense" before an update gets pushed. This makes a fair bit of sense to me. Although in theory, the benefit should be captured by the description, having it be more explicit can't hurt. Another nice thing is that might then be a step in the direction of having bodhi used to propose freeze updates which has been something that has been talked about off and on for a while. And perhaps that helps to kill two threads with one stone. This one and also it then would change "stable" updates for an unreleased release be the release stream... and by making testing available and using bodhi, it would help with your visibility point above. Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
