Peter B. West wrote: > You have as yet only Glen's opinion about your pioneer LS proposal. It > might be worthwhile to wait for others to express theirs.
I don't remember the technical rule for the mathematics of accepting proposals, but with the size of our group, a -1 from anyone pretty much kills it IMO. Right now, I see only 4 developers that might express an opinion: Peter (West), Joerg, Jeremias, and Glen. AFAIR, Joerg has never officially voted, but expressed only coolness to the LS idea in general, and even less enthusiasm for the Pioneer LS. I interpreted Glen to vote -1. I do not expect a +1 from you, because Pioneer LS is predicated on LS, and LS would have to either be ditched or rendered useless to accommodate the scheme that you insist upon. So the only unknown is Jeremias -- even if he voted +1, that wouldn't be enough to carry the issue. I'm not in love with the Pioneer LS either, but viewed it as a bridge between the maintenance and trunk lines of development that would allow us to restore the "release early and release often" principle. Ideally, instead of splitting the lines of development, we would have factored the layout logic out in a manner similar to what I have done on the trunk, then started a new LayoutStrategy while leaving the existing one intact. Changes to fonts, graphics, config, Avalonization, etc. would then be added in parallel with changes to the new layout system, still allowing improvements to be released, tested, fixed, used. The Pioneer LS (RIP) was an attempt to retrofit us into that state again. No, I can see that the idea, once coolly tolerated, has now been rejected. > > It makes me realize again that maybe I was the one pulling > against the flow. > ... > > Having always pulled against the flow, I feel qualified to comment on > this. The Apache projects and subprojects like to describe themselves > as communities. I don't see that as meaning a gang, where everyone > wears the same "colours" and effectively surrenders identity to the > collective. At the other end would be a collection of developers > amongst whom no agreement on direction could be reached, and who each > pursued a separate line of development. This would render any > productive collaboration impossible. I think Apache communities > necessarily fall somewhere in between these extremes. > > Obviously, I believe there is room for serious individual differences in > approach within FOP, and by extension, within other Apache communities, > although this will vary with the maturity of both the codebase and the > Recommendation(s) of which it is an implementation. A mature, widely > used and comprehensive implementation of a stable Recommendation seems > to offer little room for alternative approaches. > > FOP is not a mature, stable and comprehensive implementation of XSL 1.0, > and XSL 1.1 is out in Working Draft, albeit without radical changes. I > don't think it is surprising that there are serious differences of > approach. I have explained my own motivations on a number of occasions. > The bottom line, though, is that I believe in the approach I am > taking, and I believe that I, or rather, the design itself, will > eventually persuade others. The *technical* issue in play here is whether FOP will be monolithic or modularized. (There is an even bigger issue about how the Open Source development model should work, but I have already said 'nuff on that subject). For the record, I have little doubt that your monolithic approach can be made to work. The question is, supposing that a modular approach can be made to work, why not gain the benefits that come with modularization? And why not, until all are persuaded to the same view, accommodate both? Your layout scheme can be accommodated within the sphere of LS. However, AFAICT, no patient LS scheme can be accommodated within your scheme for layout. So, my objection to your proposal is not that mine is better than yours, but that you insist that the trial never be had, that we cut off options for no apparent good reason. > This last part is easier said than done, for very simple reasons. I may > have mentioned before that only I, for most of the time, and Jeremias > for part of the time, have been able to work full-time on FOP. Everyone > else has a job around which he or she has to work. Given the severe > time limits, and the difficulty of coming to terms with 1) the > Recommendation, 2) the maintenance branch, and 3) HEAD, it is not > surprising that faced with a major change of design direction, most > people just don't have the time or energy to try to come to terms with it. > > That doesn't make alternative approaches worthless. Alt.design's > property handling is now bearing some fruit in HEAD, of which I am very > glad. That it took so long for this to happen is unfortunate but > understandable. > > The bottom line, it seems to me, is that if you believe in what you are > doing, go ahead and do it. The main reason I got to be a committer is > that Nicola Ken Barozzi asked why my code was being kept on my ISP. He > said that anyone had a right to fork the code, or words to that effect, > IIRC. It's a lonely path until you do manage to persuade others, but if > you believe in it, back your judgement. Well, I don't mean to give the impression that I don't believe in what I am doing, but merely that I have been unsuccessful in my efforts to persuade others. There is a PhD on fop-user who has more than once suggested that FOP needs to be rewritten in Ada. Maybe he is right, but I don't think anyone seriously thinks that we should make him a committer so that he can start into that project, either on the trunk or a branch. The Java language, at least for now, is a settled issue. The issue of monolithic vs. modularized, while orthogonal to the language issue, is of no less magnitude. I thought that the idea of accommodating patient processing through modularization was a settled issue as well. I see now that it ain't and probably never will be. So, I believe in what I am doing, but don't see a cost-effective way, and probably no way at all, to get it done within the FOP project. I don't see any need to drag those along who don't want to come. As I said in a previous posting, if we're going to go in different directions, the "next best thing" is to part in peace and work separately instead of against each other. Whether that means forking the code, starting from scratch, throwing in with some other project, etc. I don't know. That decision is immaterial to you. But since you seemed to issue a challenge on the matter, I wanted you to know that I do indeed believe in what I am doing. Victor Mote
