[ODE] Re: unstable fixes to main trunk?

[Adam D. Moss]

Tanguy Fautre wrote:
>> Is there a reason why this is only in the unstable branch?
>> I'm afraid that everything is ending up on the unstable
>> branch, ironically even non-dangerous stability fixes.
> 
> Not really.
> I'm just playing on the safe side and considering the two last fixes on 
> the unstable branch to be "unstable" because I only tested them on two 
> computers (one 32 bits and one 64 bits) using the same Linux distro.

Okay, that's not a problem at all, as long as people do remember
to move proven fixes to the trunk too. :)

> Should I backport these two fixes into the main trunk?

I think it'd be a good idea, but I don't mind them stewing
on the branch for a while.

> Fairly easy to do so for the moment, 'cause the file were originally the 
> same as in the main trunk.

I find that it usually takes a surprising amount of tree divergence
before non-huge changesets start conflicting (though I don't
think that the CVS interface for cross-branch merging is very pleasant
at all, but that's what we have to work with!).

> I think the CVS policy is incomplete. It's stated on the wiki that 
> regular fixes should go on the main trunk.
> But does that mean that:
> - you implement them in the unstable branch, then backport them into the 
> main trunk?
> - or you implement them only in the main trunk?
> - or ... ?
> Always introducing the fixes and modification through the unstable 
> branch first as the advantage of maintaining some coherency between the 
> unstable branch and the main trunk.

Good question.   I think the answer is that the branch should get
everything that goes into the trunk, but the trunk only gets the
stabilized and proven parts of the branch, and the submitter should
use common sense regarding whether their submission is stabilizing
or destabilizing to establish whether it goes straight into the
trunk.

The danger is that things get dropped into the unstable branch
and that's that.  Such behaviour would end up with a stagnant trunk
and an undeployable branch, with too much divergence for this to
really be rectifiable.

--Adam
-- 
Adam D. Moss   -   adam at gimp.org