Jeremias Maerki wrote: ... > ATM. But even I am confronted again with the wishes of my employer to ... > of times that this will be a lost effort. But the fact that we currently > can't bring together enough manpower to make a 1.0 developer release a > reality soon gets in the way again. > > I think the only thing we can do is live with the facts but make everyone > see how working on the maintenance branch is a dead end.
I realize that I am jumping into this conversation in the middle. I am ignorant of the history of how we got where we are, so **please** understand that I am not being critical. My first exposure to an open-source project was when I started monitoring this list on July, and I have no idea how other projects operate. However, I have done some reading on the subject, and my reading generally agrees with my own intuition. I think we are in danger of violating a cardinal principle of open source development, and indeed of software development in general -- that you operate as much as possible with code that works. Unless you have massive amounts of resources (and probably there as well), the only model of software development that seems to work is an immediate feedback loop. The sequence is 1) recognize a need, 2) implement (plan and code), 3) test, 4) answer the question, "Is the code better with this than it was before?" 5) iff "yes", check it in. Now, I understand that sometimes you come to a chasm like the redesign. (I am not yet smart enough to understand the issues, but I will take the gurus' collective word for it). It is not practical to complete the entire work in one step, yet you still need a place to record the incremental changes as you move along. In other words, first you break it in some radical way, then begin to fix that break around the new design -- again, with immediate feedback. I think this is what branches were designed for. You can break-and-fix as much as you want in the branch without hurting the code in the trunk. This leads to a discussion of our CVS repository. If what I said above is correct, we essentially have our trunk and branch reversed. This was probably done with good intentions, but there are some perverse effects. Chief among these is the effect it has on the amount of code that has been branched. If I understood Keiron correctly, the redesign only really affects code in a limited number of packages. The FO tree and renderers, for example, I think should not be affected. However, changes to the working code branch are much more widespread. By putting the working code on a branch, we have forked a whole bunch of files that really don't need to be forked. The merging aspects of this are minimal, but it basically means that people working on the trunk (the redesign) can't see changes that are made to the working code until that merge takes place. The way we are set up now, the same set of changes need to be submitted twice, or else need to be merged at some future date. If we had these branches positioned properly, changes made to common code would be seen by everyone. (I am not a CVS expert, so please correct me if I am wrong -- I am assuming here that people working on a branch should use checkout -f to get files that are not on the branch from the default branch. That way they get a complete sandbox, even of files that are not on the branch). This includes all of the style work and refactoring work that is currently going on. In most cases, it only needs to be done once, with no merging. Another bad effect of our current arrangement is the false unification of documentation. This discussion, however, is probably big enough to require a different thread. There are some pernicious psychological effects at work here as well. If making working code better is causing fragmentation (I am unclear about whether this is what Keiron meant), then we have really shot ourselves in the foot. I understand that there is a cost associated with reviewing and disposing of patches. However, I don't think that is the real issue here. The real issue appears to be that when we have people working on areas of the project apart from the redesign, some assume that those are resources that really ought to be spent on the redesign. Jeremias has already pointed out one instance where this is a false assumption (an employer that is willing to have him work on working code, but is unwilling to have him work on redesign). My situation is another. I don't know enough yet to be of help in the redesign. I must crawl before I can walk, and working with code that works is the only way I have devised to learn what is going on. I will learn this stuff ten times faster if I can work on real issues. If patches that are submitted to working code are a distraction, I can build a separate local repository and commit my changes there. However, this frankly seems to be much more fragmentary, and to violate the usefulness of open source. I guess in summary, I have to respectfully disagree with the idea that working on the maintenance branch is a "dead end". Work on the maintenance branch in areas that the redesign addresses is probably dead end, but I see no reason why that must be true for the project as a whole, except for the mechanical problem that exists in our repository. I propose that we stop & take the time to reverse the two lines of development in the repository, merging where necessary along the way so that our code is reunified to the extent possible. Alternatively, perhaps a CVS guru can see a better way to accomplish the same thing. I hope that no one views this as a lack of confidence in the work being done on the redesign -- I simply don't know enough yet to comment one way or the other. Also, I apologize in advance for breaking this hornet's nest open -- this is probably an old discussion. If it is a settled issue, I'll try to adapt myself to it, but I think the effect of this tends to freeze out new developers until the existing ones complete the redesign work. This seems to me to be a risky and unnecessary strategy, an attempt to force behavior that realistically can't happen. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
