Keiron Liddle wrote:
> Actually projects like mozilla have branches for maintanence but the key
> is that they are short lived, this didn't work out like that.
I don't know this, but I'll bet that the maintenance branch that you refer
to here is for bug fixes, while the main development line progresses
*incrementally* on the trunk. The reason why ours didn't work out that way
(I suspect) is because we tried to do a chasm-type change on the trunk,
where we had to break the code to go forward. With 20/20 hindsight, it is
easy to see that the chasm change would have been more convenient to manage
on a branch. In this respect, it is no different from a normal patch. For a
normal patch, your sandbox is a kind of branch. Only after the code is
completed and tested do you commit it. The only difference with a chasm-type
change is that, because it is so big, you want to be able to put incremental
changes into source code control so that can keep a history. The principle
still remains that only after it is completed and tested should it be merged
(committed, if you will) to the trunk. As you correctly point out elsewhere,
this is all water under the bridge. I mention it only because I suspect that
it explains the difference with mozilla.
> 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.
I think I understand. However, the question is not the quantity or even
location of the changes that have been made, but the scope. The real
question is how many of the changes that have taken place in the trunk are
changes that were applicable only to the trunk -- in other words, are a lot
of them changes that would have helped or at least not hurt the maintenance
> 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.
I didn't mean to imply that the branch is mostly OK, but I understand your
> 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.
This seems to support my point that some of the files were unnecessarily
forked, but I sure might be missing something again.
Also, it is possible that, even if the unnecessary forks could have been
prevented in the past, the fact that they took place has led to unfixable
differences. For example, if one branch was refactored for X, and the other
was not, it will be more difficult to merge them now. I suspect that your
MessageHandler citation is such an example, as I was imitating other
maintenance branch code.
> 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
The key here is to divide the differences between the two branches into two
groups: 1) those that *must* be different between the branches or that
cannot be efficiently reconciled, 2) those that can (efficiently) be merged
without breaking either branch. If the differences are heavily in the first
class, we should just continue on from where we are. If they fall
substantially in the second class, then the plan you propose above makes a
lot of sense.
While we are in a brainstorming mode, please forgive me for throwing out
another wild hare to consider. (This only makes sense if most of the
differences are in the second class): Is it at all feasible to maintain both
layout managers in one set of code? In other words, for the choice to be
selectable or pluggable? Perhaps put the old logic into an oldlayout
package. If there is a lot of potential commonality between the code, this
would give us an opportunity to reunify the two branches right now, and
simply blow the old stuff away at some point in the future when it is no
longer needed. It would be worth *a lot* to get the branches unified if at
If it is not feasible to unify significant portions of the two branches,
either by switching them in the repository or by putting them into one
branch, then I propose that we clarify our terminology by using the term
"rewrite" instead of "redesign". This would signal that we are not merely
rebuilding an important module, but that the changes are pervasive, and that
the old code has been effectively abandoned.
Keiron, I'm sorry to keep asking you to answer the same question over and
over again. I guess I've never had to totally abandon useful code before
(however moderate the usefulness might be). If, after considering the above
points, you are sure that we are on the right track, I'll do what I can to
be useful on the trunk. Unless you have a better idea, I'll continue with
the font work -- just understand that the refactoring work will be much more
likely to introduce bugs when I am flying blind than it would be with
Thanks for your patience.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]