----- 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@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
