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