Broken upgrade paths in F7

Patrice Dumas pertusus at free.fr
Tue May 15 17:11:34 UTC 2007


On Tue, May 15, 2007 at 11:13:07AM -0400, Jesse Keating wrote:
> 
> To be perfectly honest, I'm not completely happy with this process for the 
> final freeze either.  This was an experiment for the Fedora 7 release, and it 
> went really well for the test release freezes.  I agree that the final freeze 
> should be done differently, however I didn't want to change it at this point.

Agreed. I think it should be changed for the next release, it is to late
to change it now. But I wanted to voice out my concern so that things
are changed next time. I already complained at the first time the release
process was outlined but nobody cared. (As a side note, for the freeze 
there was still plague used and we hadn't to ask to push so of course it 
was better than for the release.)

> Asking how many were rejected isn't quite fair.  It's not the people who are 
> asking for tagging that I'm concerned with, it's the people who just don't 
> realize we're in a freeze and happily drop in a soname bump that breaks a ton 

That shouldn't happen if instead of make build, one have to do 
make release-build 
when we are in freeze.

> of packages or other such acts without noticing that we're in a freeze and 
> doing such can cause problems with the release.  This has happened in the 
> past, I'm not just being overly paranoid.  I very much want there to be less 
> overhead, and I welcome any effort into the workflow that gets us there, but 
> at the same time we have to be able to manage a freeze and have control over 
> what gets in and what doesn't.  

That's why I think that rel-eng people could disallow a push and should
have the last word, at least until the packager had time to say why he
wants it. That's what was done for extras and it worked well -- although
I agree that how it was done in extras is not necessarily suitable for 
merged fedora, especially because of the constraints linked with
composing the release.

--
Pat




More information about the Fedora-maintainers mailing list