Peter B. West wrote:
> Victor Mote wrote:
> > Victor Mote wrote:
> >
> >
> >>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.
> >
> >
> > Upon further consideration, I would also recommend that, in the
> above case,
> > we actually put the code into two different projects.
>
> I don't see that anything would be gained, and much would be lost.
>
> > 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.
>
> > and I think that is part of what has been confusing me. By
> > cutting that tie, it would be clear that there will be no merging. Right
> > now, we are kind of half in and half out, and it would be good to signal
> > whatever decision is reached definitively, mostly for the
> benefit of those
> > of us (me) who are slow to catch on.
>
> I'm sorry, Victor, but this makes no sense to me at all. It's the same
> project, and its future lies with the redesign (not rewrite, as I
> pointed out in an earlier message.) The fact that it was branched has
> meant that development has been able to continue in the maint branch.
I now understand Keiron to be saying that it is a rewrite. By rewrite, I
don't mean from the ground up, but I mean that the old code is abandoned. I
am trying to get clarification of this very point.
>
> I agree that the major layout redevelopment should occur on a branch.
> There has already been a lot of time spent on it, and it will take some
> considerable time yet, during which the layout will be pretty much
> broken. So yes, I think that the effort should be made to switch the
> branches. A lot of the useful improvements (the redesign of logging,
> the new configuration mechanisms, etc.) can equally well be applied to
> the existing code, and FOP gives the appearance of being constantly
> improved.
This is what I assumed as well, and I have been operating on the idea that
the two branches would eventually be merged, with any conflicts resolved at
that time. I am now hearing (I think) that one of the following (perhaps
both) have occurred: 1) the redesign changes have become pervasive, or 2)
because we forked code that was really common to both branches, we now have
artificial differences that will be difficult to bring back together.
>
> Meanwhile, the new layout engine can be developed fairly independently
> of the plumbing. It doesn't matter what logger, or configuration
> mechanism or image handling the new layout engine uses in development.
> When it is complete, the merging of all the applicable changes to the
> maint branch would occur. How would this be done from another project?
>
> One of the problems that Keiron may have foreseen with this is that most
> development effort would focus on the maintenance branch for short-term
> results (and kudos) while the new layout engine languished for want of
> love and attention. It's a real concern, made all the more real by the
> tenor of these suggestions.
Please note that my proposal was carefully predicated as follows: "If it is
not feasible to unify significant portions of the two branches, ...". You
are arguing that it is feasible. If that is true, then I agree that we do
not need another project. It is abusive to argue against the proposal
outside of its context.
Here is the algorithm:
1. if the two layout mechanisms can be runtime-selectable
and coexist in the same set of source code:
a. merge the two branches to accomplish this
b. return, break, stop, whatever -- you are done
2. if the two layout mechanisms need to live in separate
source code branches, and there is a lot of common
code between them, and that code can be efficiently
merged:
a. decide where the reunified portions should live,
trunk or branch
b. merge the common code to that location
c. fix the branch tags for the common code so that
anyone checking out or committing code to
either branch will always
get exactly the same piece of code
d. update doc as necessary to support the mechanics
and to explain the logic
e. return, break, stop, whatever -- you are done
3. If benefit can be shown to leaving code that will
never be merged in the same tree:
a. update doc to explain
b. return, break, stop, whatever -- you are done
4. Split the code into two projects
5. Update the doc to explain
5. Return, break, stop
I hope this helps.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
