-----Original Message----- From: Joshua A. Andler [mailto:scislac@...400...] Sent: Wednesday, November 04, 2009 02:40
How do we define "major"?
Well, typically something that we would label as a refactoring task. However, if someone has a "major" change and throws it in a branch and it is deemed to be safe enough to be worth the possible risk for 0.48, we'll merge it.
I'm not sure whether it is the refactoring that troubles this release.
I don't know what my opinion is. Having bug-likely stuff in a branch is nice of course.
However, a practical problem of large refactoring is that it touches the source in many different places. This makes it very likely that changes in trunk coincide with refactoring changes in the branch. A lot of time (and frustration) will be spent merging in changes from trunk. This is also true for non-refactoring but invasive new features, like LPE was.
Moreover, very few people test branches. I remember Josh (ScislaC) and sim (?) being the only ones who regularly checked out my LPE branch for testing. A branch was used for group/stacked LPE, but perhaps two people (other than the devs) tested it a little. Many bugs are discovered late, and it seems a branch will only delay that. On the upside, there are also a lot of bugs that are discovered early but the bugreports reach the developer(s) very late or not at all; the upside is that when a branch is used, the bugs are easier to target to a specific branch and to specific developer(s).
I think more important than a branch is a teamed effort for big projects. From my own experience, refactoring alone is no fun; refactoring in a team (thanks Verbal and Diederik!) is much more fun. So I feel that before anyone should take up refactoring, he should find a team to do it with. This reduces the risk of 'vacation' or 'sick of it' problems.
Ciao, Johan