Re: Common code in CVS branches

[Peter B. West]

Jeremias Maerki wrote:

Peter

This is an idea I was also playing with. Avalon does that, too. But
having multiple subprojects (that's what they are, not modules) brings

My sloppy use of the term "module".

it own difficulties. There are several pros and cons to this:
+ Encourages loose coupling and good design
+ Components that could in theory be used independently of FOP would get
a better visibility. + Reduces redundancy/code duplication
+ It is easier for newbies to start working on FOP because they don't
see a big bundle of code at once.
- dependencies get more difficult to handle
- encourages the development on the old FOP (which I don't think is a
good thing)

In the case of common code, work on the old FOP would also be work on the new FOP, wouldn't it?

I've found more pros than cons but I'm not sure I like it.

Comments on your thoughts about branches: It sounds like the CVS
manipulation gets to be a project of its own. If it's too complicated,
some won't follow the rules, more work is generated for maintaining the
codebase. That's the impression I get.

It's definitely 1) more complicated, though not massively more so, and 2) requires closer liaison between committers on common code commits.

1) bad
2) good?

FOP has lost a lot of its maintainers last year. New ones have been
elected into the project but we're still in a resource shortage. I'm
glad we have a few new candidates coming up. As we've discussed in
August, I think it's VERY important to focus our work so we can get that
redesign/rewrite phase behind us as fast as possible. Having to watch
dependencies in this process is braking these efforts. If changes are
being performed in the maintenance path that can later be ported to the
redesigned FOP then I have nothing against it. Examples can be those
given by Keiron. IMO font support is also pretty separate. Also, bugs
should also be fixed if they are easy to fix. But please, let's put our
efforts together to bring FOP to a version 1.0 as soon as possible. A
lot is already there. We can build on that.

I concur with Oleg here. (Yes, really.) However, there are people who, as Victor has said, who find the all-or-nothing approach extremely difficult. If they can come up with practical ways of easing such difficulties, their suggestions should be carefully considered.

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]