Fedora Release Engineering Meeting Recap - 2009-05-04

Jeremy Katz katzj at redhat.com
Fri May 8 13:22:10 UTC 2009


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




More information about the fedora-devel-list mailing list