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]

Reply via email to