Hi Victor, I'm lost for ideas. I'm getting the feeling that this project is simply too large for this situation. Which is why I want the effort to be focused and not wasting time sorting out things that don't get us anywhere.
On Thu, 2002-10-31 at 20:30, Victor Mote wrote: > 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. That sounds very good and is probably works almost all the time. The fact is that it was not working. And as they say, "It seemed like a good idea at the time". Circumstances change and we need to deal with what is now. Actually projects like mozilla have branches for maintanence but the key is that they are short lived, this didn't work out like that. > 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. I think you have misunderstood something. There has been a great number of changes across many packages and classes in trunk. The reason being that the code was (and still is in the branch) in a bad way, this occured gradually more because it wasn't prevented from hapenning. For example the link support, pdf library, image handling. It becomes quite obvious when you understand why there are so many bugs with link positioning, image handling and further causes of memory leaks, excess memory usage. > 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. I think it is the opposite, that changes on trunk are much more widespread. > 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. This is what seems to be the real problem. You think that the branch is mostly okay and only some of it has changed in the trunk. This isn't really the case. Now lets take the PDF library for example (it applies just about everywhere in the branch due to code being linked all over the place). The code in the trunk is more advanced in a number of ways. Such as transparency, link handling, image handling, gstate, graphic state. Now if you are to improve the code in the branch it will mean either it has already been done or that the changes will need to be brought across from old code to new changed code. In some cases the changes will compound old problems (for example you used the MessageHandler). Now if the improvements are made in trunk this is more likely to be handled better, the code could then go across to improve the branch. > 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. The only realistic merge that I can see is bringing across the following to the branch: - pdf lib - svg - image handling maybe - renderers - area tree There isn't really that much on the branch that is relevant to the trunk. The thing the branch has is that the layout works (sort of) and it is a complex beast to do properly. Maybe the simplest is to move the old layout to the trunk, get that working and put the new layout in a branch. But it needs to be agreed upon. Keiron --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]