----- Original Message -----
I'd like to see a rationale for jamming a soname-changing update
into
the OS so close to a release. In the absence of a very good
motivation,
that's not good engineering practice, and it's not consistent with
the
feature process.
Perhaps you're not clear on what the word "freeze" means.
One rationale is that if we don't get it *before* the release when everyone is
actively testing, then it ends up going in post release, likely with far less testing, and
risks destabilizing the already released product. Unless we want to change the Fedora
update policy that updates such as this are not allowed after the product goes GA, then
there is an argument to be made that before GA when people are testing is better than
after GA when testing isn't so widespread (the counter argument being that we need to
stabilize what we have, and then deal with destabilizing changes in later updates because
if we don't pick some line in the sand to call a stabilization point, then
destabilizing changes will never end).
However, if a group were to take this approach, then the entire CRITPATH and normal update
process for an early branched release is totally backwards from what it should be. If we
were to say that we want the stuff in early instead of post-GA, then on an early branched
process things should go direct to stable without hitting testing at all on the theory
that getting it in the most hands as quickly as possible maximizes testing prior to the
product going GA. Yes, it might destabilize the early branched release momentarily, but
without anything blocking a fix from being pushed right on out, the iterative "push,
test, report breakage, fix, push, test" cycle goes much faster.
Note: I'm not putting my $.02 in towards either side, just playing devil's
advocate.
--
Doug Ledford <dledford(a)redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford