On Mon, 04 Nov 2002 10:22:14 +1000 Peter B. West wrote: > 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?
Yes, for peripheral components (PDF lib, fonts etc.). > > 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? I can't follow you on 2). Do you mean between maintenance-oriented committers and redesign-oriented committers? If that gets a problem then we have a split in the project and that wouldn't be 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. I fully agree with you. That's why I mentioned my employer who actually understands the reasons for the redesign and looks forwards to FOP 1.0, but thinks that there are certain issues that have to be dealt with right now. That's why I'm going to look at multithreading issues in the maintenance branch this week. If we had enough resources (like in Jakarta Tomcat, XML Xerces and XML Xalan, where they maintain/maintained two or more dev tracks at once) I wouldn't mind a two-track-approach. But in our situation I tend to force the redesign so we can deliver FOP 1.0 as soon as possible. I'm grateful for Victor's work and I hope it won't be a distraction. Because distractions may leave the focus of potential co-developers on the maintenance branch even though the redesign is already quite advanced. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
