No subject

d=2C <BR>
&nbsp=3B * for the people wanting to do public beta grade services based on=
 OpenSim<BR>
&nbsp=3B *&nbsp=3Bfor developers that want to code on modules without sudde=
n mysterious breaks<BR>
&nbsp=3B *&nbsp=3Band for the devs that want to debug without new parameter=
s being introduced.<BR>
&nbsp=3B<BR>
Now of course=2C vendor branches is one other way to do this=2C but what we=
 at Tribal realized=2C was that since we're coding in modules=2C all we use=
d the vendor branch for was for stabilizing fixes.<BR>
&nbsp=3B<BR>
And since that work would otherwise be duplicated in a number of dev teams=
=2C it makes sense to share that work.<BR>
&nbsp=3B<BR>
&gt=3B&nbsp=3BA better approach to stability than stable branches is<BR>&gt=
=3B to help create unit tests for trunk. <BR>
&nbsp=3B<BR>
Which of course not only is a totally untestable assertion=2C but also has =
to be weighted against a pragmatical timescale.<BR>
&nbsp=3B<BR>
&gt=3B This helps contain behavior=2C and<BR>&gt=3B drives towards code cor=
rectness for parts of the tree. <BR>
&nbsp=3B<BR>
+1 to extended testing.<BR>
&nbsp=3B<BR>
&gt=3B I'd encourage people<BR>&gt=3B spend time on enhancing automated tes=
ting instead of doing point in time<BR>&gt=3B stable branches.<BR><BR>
I'd encourage people to do both=2C as&nbsp=3BI believe compairing the effor=
ts would be like&nbsp=3Bcompairing apples to pears. One is about testing th=
e correctness of the code in a point of time=2C the other is to provide an =
aggregate of experience to facilitate&nbsp=3Ba work process.<BR>
&nbsp=3B<BR>
At heart=2C I'm an agile coder. I do believe that trunk should always be in=
 a shippable state=2C but to think that that means you should always ship t=
runk=2C is to over-simplify.<BR>
<BR>/Stefan<BR>
&nbsp=3B<BR></body>
</html>=

--_8c91159c-18de-4961-9531-c53f449079b8_--