No subject
Sat Apr 19 01:31:08 UTC 2014
d=2C=20
* for the people wanting to do public beta grade services based on OpenSi=
m
* for developers that want to code on modules without sudden mysterious b=
reaks
* and for the devs that want to debug without new parameters being introd=
uced.
=20
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.
=20
And since that work would otherwise be duplicated in a number of dev teams=
=2C it makes sense to share that work.
=20
> A better approach to stability than stable branches is> to help create un=
it tests for trunk.=20
=20
Which of course not only is a totally untestable assertion=2C but also has =
to be weighted against a pragmatical timescale.
=20
> This helps contain behavior=2C and> drives towards code correctness for p=
arts of the tree.=20
=20
+1 to extended testing.
=20
> I'd encourage people> spend time on enhancing automated testing instead o=
f doing point in time> stable branches.
I'd encourage people to do both=2C as I believe compairing the efforts woul=
d be like compairing apples to pears. One is about testing the correctness =
of the code in a point of time=2C the other is to provide an aggregate of e=
xperience to facilitate a work process.
=20
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.
/Stefan
=
--_8c91159c-18de-4961-9531-c53f449079b8_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
>=3B >=3B I can see some people being hesitant to commit to supporting =
this<BR>>=3B >=3B because they don't want to worry about committing to =
two branches each<BR>>=3B >=3B time they have a fix=2C or they don't wa=
nt to maintain two slightly<BR>>=3B >=3B different code bases.<BR>
 =3B<BR>
This would be 100% optional=2C and probably done by a small group of devote=
es (like me and Darren=2C as in the case of the last stable) whose only hum=
bly wish is to get a heads-up from peple whenever =3Ba good=2C clean bu=
g fix has been committed.<BR>
 =3B<BR>
>=3B >=3B =3BBug reports could also become more of a hassle as<BR>&=
gt=3B >=3B some users will report bugs against the trunk=2C while others =
against the<BR>>=3B >=3B stable branch.<BR><BR>
My concept will not work if we don't re-branch new stables reasonably often=
- the heart of the concept is that 'stable' should not deviate from trunk =
very far at all=2C just minor bug fixes and changes deemed 'harmless'.<BR>
 =3B<BR>
The reason=2C of course=2C is exactly that we should be reasonably certain =
a bug exists in both branches.<BR>
 =3B<BR>
Apart from that=2C we have that same problem on every revision. The user ne=
eds to tell us what revision (or trunk) the error is on.<BR>
<BR>>=3B >=3B Having said that=2C I can see a benefit for having a stab=
le branch.<BR>>=3B >=3B Ideally it would follow trunk pretty closely=2C=
and when it becomes<BR>>=3B >=3B challenging to apply patches to both =
trees without too much massaging=2C<BR>>=3B >=3B it's time to do final =
stabilization on that final branch and release.<BR><BR>
That was the general idea. Bu tI would say=2C given the agile nature of the=
project=2C that we just _define_ that=2C "when bug fixes does not apply cl=
eanly=2C it's an indication we should bump the number".<BR>
<BR>>=3B >=3B I would like to encourage you to give this a try.<BR>
 =3B<BR>
We already are. At the moment=2C I'm just waiting for people to tell me we =
have a reasonably stable revision that I can branch again.<BR>
 =3B<BR>
>=3B =3B>=3B In the meantime=2C don't expect too much<BR>>=3B >=
=3B commitment from all the devs=2C and be prepared to take responsibility<=
BR>>=3B >=3B for this stable branch. After some time=2C we can all look=
back at how<BR>>=3B >=3B things went and decide what to do in the futu=
re.<BR><BR>
This is basically what happened with 0.6.0-stable. Only thing we need is he=
lp with finding the revisions=2C and to get tipped about good stabilizing&n=
bsp=3Bfixes in trunk.<BR>
<BR>>=3B The problem with stable branches... is they aren't. If you add c=
ode to<BR>>=3B a branch=2C you have the potential to break it=2C especial=
ly on a source<BR>>=3B base as complex as OpenSim.<BR><BR>
True as that may be=2C =3Bof course it depends on what type of code you=
add=2C and how much.<BR>
 =3B<BR>
If we were talking doing serious work on a 'real' branch=2C I would be much=
more inclined to agree=2C but the point of this is to keep it ligth=2C agi=
le and to a minimum of deviation.<BR>
<BR>>=3B Personally=2C I'm going to stay focused on trunk=2C that's where=
my time and<BR>>=3B interest lies.<BR>
 =3B<BR>
Then do. I'm not trying to rally resources devoted into this=2C I'm merely =
trying to work out a process that would work given the nature of the OpenSi=
m project.<BR>
 =3B<BR>
More information about the Opensim-dev
mailing list