Branko Čibej wrote:
> Say what? If trunk is unstable, that's clearly in violation of the
> policies that we set down on day 1 and someone needs a big stick applied
> to their pants.
I suspect that are two different concepts of "trunk must be stable" here,
and it would do us good to understand them and better define which of them
we mean in our conversations.
The first idea of trunk/branch stability is somewhat rigid, but easily
verified: the code builds without error or unexpected warning, and all the
tests pass. This is, I believe, the definition of stable that we've always
applied to the "trunk must remain stable" rule.
The second idea is harder to pin down, but refers to the degree to which the
various features and enhancement being developed on a branch are inline with
their *intended* state.
So, trunk could be stable in the first sense (because building and testing
goes perfectly) while being very unstable in the second (because some
compatibility logic is missing from a new FS feature, or because tree
conflicts only partially work, or because the APIs haven't been properly
incremented and deprecated, or...).
IIUC, today we have the worst scenario -- trunk isn't stable in either sense
of the word. We absolutely shouldn't branch in this condition, because it
is an outright violation of our policies. But assuming we achieve type-I
stability, the question then becomes whether we require type-II stability
before branching. This is probably something that needs to be codified in
our release management procedures.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-11-11 16:16:59 CET