<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>> > as much as we all want osgrid to move forward, we should really tag<BR>> > 2060 as osgrid-stable-grid-0.4 and 2204 as osgrid-region stable-0.4<BR>> > and tell all people on osgrid to use THAT instead of trunk until we<BR>> > figure out what the hell is wrong.<BR>> <BR>> Though, we won't figure out what is wrong if everyone hangs back at safe<BR>> versions.<BR><BR>
Well, our need to have our debuggers using the latest rev should be balanced against our need to push forward. I think this will mean we all try to make sure it moves forward.<BR>
<BR>> > Also, if we want to supply some kind of stable experience, we should<BR>> > start _branching_ as well, bugfixing for that branch and selectively<BR>> > merge the bugfix back into trunk. You want stability or latest<BR>> > features? You can't have both.<BR>> <BR>> I really think history has shown that merging + svn = more pain and<BR>> agony than anyone really can put up with.<BR><BR>
Well, these _branches_ aren't meant to be merged back, that's what I meant with 'selectively merge the bugfix' - either you do an actual diff merge, or you just re-fix the bug in trunk.<BR>
<BR>
My point is that that 'stable branch' should only be _bugfixed_. New features goes into trunk.<BR>
<BR>> > The situation we have now with the core devs (newbs and oldes)<BR>> > tip-toeing around, being afraid to introduce bugs, because anybody<BR>> > could be expected to pull trunk and run it is just absurd. Also, it<BR>> > leads to n00bs like myself not being able to learn by 'trial and<BR>> > error' because we don't tolerate error. And yes, I do mean 'trial by<BR>> > error' by committing - bughunting should be a community effort and<BR>> > thus a community learning experience.<BR>> <BR>> Keeping the quality of trunk high is more important on the development<BR>> front than the user front. We've got 13 committers now, all working on<BR>> different schedules. If someone breaks trunk in a bad way, the other 12<BR>> can't get things done. Mistakes happen, but testing prior to commit<BR>> really needs to become part of our mantra if we're going to continue to<BR>> work as productively with so many developers. :)<BR>
<BR>
As much as I do agree, testing now comprises so many scenarios that just testing for all scenarios would take longer time than actually coding, especially when working with functionality that touches grid code.<BR>
<BR>
This project is alpha. We are blessed with tech-savvy people that have set up grids (several, in different environments and with different degree of heterogenity) - I say we _use_ them as a development resource, instead of devoting precious dev time to manual setup and testing in _fear_ of them. It should be up to each grid and region maintainer to test revisions and decide whether to move forward; what the devs can do is to provide _information_ about different revs, what to stay clear of, what's considered safe, and what needs testing.<BR>
<BR>
/Stefan<BR>
<BR></body>
</html>