Re: handling patches

[Peter B. West]

Victor Mote wrote:

Oleg Tkachenko wrote:

Victor Mote wrote:

Branches imply
eventual merging,

Not necessarily.

I'll be happy to consider this point if someone will name even

one benefit

to keeping code that will never be merged in the same tree.

Well, the main idea of branches is just to split development, e.g. for
the sake of some release bug handling, but branches are not obliged to
be merged eventually. Usual development pattern is to branch a release
code and continue development with no care about it (bugs are fixed in
the branch) and when a new release is ready all patches and bug fixes in
branched code *may be* just irrelevant because of new (e.g. redesigned
:) implemention.
Following this pattern, development of branched code is just ugly mess
as it's first of all *maintenance* release.

I agree that maintenance branches are not obliged to be merged eventually,
but you still have not shown any benefit to keeping them in the same tree if
they are not.

I don't have the benefit of seeing the future. Oleg says "*may be*", and that encapsulates things nicely. Branched code *may be* just irrelevant, or branched code *may be* just relevant. Who knows? But if the code shares common ancestry, it's a far bet that at some time in future useful cross-fertilization may occur. Version control systems are predicated on uncertainty. If I *just know* that this version of the code is perfect, there's no need for me to hang on to the old stuff. In fact, complete records of the development, captured in the CVS/RCS/SCCS/whatever source trees, have turned out to be extraordinarily useful in the real world.

As for divergent branches, how else do new divergent versions come about. A new version starts as an idea for development which is going to diverge from the existing code. That implies that its starting point is the existing code. When it develops to the point where it can stand alone, and take over and extend the existing functionality, you can create a new tree, based on the divergent branch from the old. Not, of course, am empty tree.

That new tree will share ancestry and a lost of common code with the old one, but, because the full functionality exists in the new tree, users can be told that no further development will occur on the old version. At this point, only critical bug fixes will be contemplated on the old branch, and the probability of these being required on a mature product will be considered low. That low probability extends to the probability that such changes will have to be manually incorporated into the new tree. After a while the first tree can be retired, as not even bug fixes will occur. At that point, two divergent lines of development will exist in the tree, and will have existed for some time.

Even if you have development resources to burn, you approach things conservatively. While the branches are in the same tree, it remains feasible, if increasingly difficult, to perform merging. And, if, like me, you cannot see the future, you want to keep such options open. We do not have development resources to burn.

Usual development pattern would also be that someone makes sure that new
functionality doesn't get added to the maintenance release. That is
apparently what Keiron is attempting to do now, and I have no problem with
that. However, our web site says this:

"If you want to work with the latest and nicest code, you can use the cvs
version. See the section on AnonCVS in the xml.apache.org documentation for
details....

"Important: Currently, releases of FOP are coming out of the
"fop-0_20_2-maintain" branch. The "MAIN" branch is used for the redesign.
See NEW DESIGN for more information."

I hope I will be forgiven for not correctly interpreting the multitude of
mixed signals.

Yes, there are a couple of mixed signals which require clarification.

Let me say (re another message) that I am not asserting anything about the feasibility of any approach. I am stating a preference for the future direction. Those qualified to assess the feasibility of any approach are, firstly, Keiron and Karen. Karen is otherwise engaged at the moment. The people who have taken the next most comprehensive look into the code are probably Joerg and Jeremias. I hope I haven't offended anyone here; speak up if I have. These are the people who can comment about feasibility.

If you are looking for a rewrite, go no further than FOP_0-20-0_Alt-Design. That's a rewrite, from the ground up. Yet it contains pieces of the 0.20 code. And it is staying in this tree, because I plan to do some major, time-consuming, finicky, tedious merging later on. in order to benefit from a number of recent developments which I have no intention of writing myself.

If you took offence from the "short attention span comment", I am sorry. No such offence was intended. The comment concerns the general approach to development that you mentioned.

Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]