Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo

2008-04-21 Thread Andreas Delmelle

On Apr 21, 2008, at 12:22, Vincent Hennebert wrote:


My reaction was not so much triggered by this (indeed) minor issue, as
by the fact that once again I was being answered “feel free to  
improve”
when asking for cleanup/documentation, and I got tired of it. Each  
time,
they were small issues that were not a big deal in themselves, but  
when

combined together make the code IMO unnecessarily difficult to
understand. We are dealing with a very complex piece of software,  
so it

looks even more important to me to keep the code as clean and readable
as possible. Actually I consider this to be my duty whenever I commit
something, and not spending the little time this requires for that
eludes me completely.


FWIW: I think you do have a major point here. If it really concerns  
documentation, it's /always/ better if this is kept up-to-date by the  
dev that committed the changes in the first place. Someone else is  
much more likely to make errors in interpretation. Only the creator  
knows precisely what a certain part of the code is meant to do.


Cleanup is maybe more subjective than documentation (*), but that  
said, some simple rules of thumb would probably not hurt here.


In this last case, however, I got the impression (as Jeremias, I  
presume) that it was not about documentation or cleanup.
I initially read it more as a suggestion --What would you think  
if...? As such, Jeremias' reaction was very understandable to me, and  
it surprised me to see it escalate further.


(*) as in: My apartment is clean enough for me, but I know of people  
that would get a heart-attack if they entered here... ;-)



Cheers

Andreas

Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo

2008-04-19 Thread Peter B. West

Jeremias,

For what it's worth, I think you have done an extraordinary job with 
FOP. From my outside perspective, you have been the primary driver of 
the progress of the product since you came to the forefront of development.


There's an inherent problem of clashing egos in OS development. I know 
all about that one. When that starts to happen, project productivity can 
dive until the conflict is sorted out.


If you are feeling burnt-out, it might be time to consider tailing off 
your involvement in the project.


Let me say, however, that on at least two occasions that I remember, 
Vincent has displayed a breath-taking and unwarranted arrogance. Vincent 
has a very high opinion of his own ability and I suspect he sees himself 
as the natural leader of the project.


Unless Vincent develops some hitherto unsuspected humility and 
consideration, this difficulty can only end in one of you bowing out. 
That would be a pity.



Jeremias Maerki wrote:

On 18.04.2008 19:24:05 Vincent Hennebert wrote:

Jeremias Maerki wrote:

On 18.04.2008 16:51:37 Vincent Hennebert wrote:

Jeremias Maerki wrote:

On 18.04.2008 12:48:53 Vincent Hennebert wrote:

Hi,

A few comments:

- some time ago I created a BreakUtil class in the o.a.f.util package.
  I think this class and KeepUtil should be put in the same place.
  Perhaps we could even merge them into a unique KeepsAndBreaksUtil
  class. I don’t really know what the best place would be. I put it in
  o.a.f.util because it already contains all sorts of utility classes,
  but o.a.f.layoutmgr would also make sense. WDYT?

Whatever.

I let you choose, but please take care of this.

Whatever means: I don't care and you can fix this if it is important
to you.

Yeah, sure, let’s all do our own mess in our own corner and everything
will be fine.

I’m not asking you to finish my work, so please don’t ask me to finish
yours. You created a class that’s closely related to another existing
one that’s somewhere else; it’s your responsibility to try and maintain
some coherence in the codebase by fixing this.

Give me any good reason for not doing this simple thing, other than that
you don’t care or you don’t have enough time, and I’m shutting up
straight away. But you can’t call for contributors on one side and not
do even the most basic cleaning behind you on the other side.


Ok, let's do it this way: If one other FOP committers says that this
(Vincent's idea) is something I should do, I'll do it. No discussion.
Otherwise, it's 1:1 and I won't waste my time on something I don't think
helps in any way. Remember, this is a democracy and a meritocracy here.

http://www.apache.org/foundation/how-it-works.html#meritocracy
http://www.apache.org/foundation/how-it-works.html#committers

We've had a long discussion together around this last week during
ApacheCon. IMO, you're going too far now. I increasingly feel like I'm
your bitch. Today alone I lost almost half a day because I was too angry
to work. I couldn't concentrate on what I should have been looking into.
It's ok if you point out bugs and if I fix them because the bug is one
of mine. I'm actually grateful for that. It's something else entirely if
you have some idea and expect me to do the work. For free, notabene. I
can also send you an invoice. In that case, I don't mind the additional
work.

OTOH, if I'm creating a mess here, maybe I should leave the project in
order not to damage it any more because I care about it. Or better
revert all my changes on Trunk in the last 3 years to undo the damage.
Sorry for getting sarcastic, but it's not that far off.

The other option: we could to switch to R-T-C:
http://www.apache.org/foundation/glossary.html#ReviewThenCommit
The PMC can decide to do that. That way we're always sure the community
stands behind every change. But of course, you know what that would mean
for the project.

FOP community, if you think I drifted out of line lately, please set me
straight. Vincent's voice is only one. I know this scene here is ugly
and nobody wants to waste his precious free time on participating in
fights between two people. The fight also doesn't help the project at
all. Quite the opposite. In the case of Avalon.. Anyway, I keep
finding myself in confrontations with team members from time to time. At
this time, I'm seriously questioning myself and I'm not sure if that's
just me and my thick head, if I care too much about the project, or if I
simply have more attack area because I'm one of the most active people
here. Some hints would be great (on- or off-list). Please be frank.
Thanks and my apologies for the ugly scene!


Jeremias Maerki (whose boss is Jeremias and to a certain degree the XML
Graphics PMC, but certainly not Vincent as an individual)






--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/


Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo

2008-04-19 Thread The Web Maestro
On Fri, Apr 18, 2008 at 12:52 PM, Simon Pepping [EMAIL PROTECTED] wrote:
 Easy please. Vincent has a preference. Jeremias is OK with it, but he
  is not hot about it, so he is not going to do it. Vincent did not add
  the new utilities, so he is not going to do it. That leaves Andreas to
  do it, or me, or ..., or it remains undone. Fortunately, that would
  not create a mess.

  Jeremias has never been in the habit of creating a mess. Nor has
  Vincent. But Jeremias does not code in the manner of Vincent, nor does
  Vincent in Jeremias' style. We have to live with that diversity. FOP
  is that sort of project. It benefits from that diversity, because the
  project has so many diverse sides to it. But the style will never be
  uniform. Alas?

  Simon

Considering that Open Source project rely on many individuals working
together, for better or for worse (not unlike a marriage ;-), civility
and tolerance are paramount. Expression is also of great import, and
it can be tough to communicate freely via email, without
miscommunication occurring. That's why I generally take a moment
before responding if I feel my temperature rising... I also make an
effort try to send my thoughts offline to others I trust, to ensure
they're not 'too hot' and cause undue issues.

As far as this issue is concerned, this being FOSS, if someone has an
itch to scratch, they're generally free to scratch it. Like Simon
says, Jeremias doesn't feel strongly about combining/optimizing this
portion of code. IMO (and apparently Simon's  Jeremias') if Vincent
feels a need to optimize, he can either optimize or let it lie until
someone gets an urge they feel the need to scratch.

Vincent, my hope is that you won't take this as 'beat up on Vincent
week'. On the contrary, I think it's more about building community,
and I believe all of us (even those of us who mainly lurk or are
'inactive') have valuable wants and opinions. Expression is an
important part of every healthy relationship and community.

Regards,

The Web Maestro
-- 
[EMAIL PROTECTED] - http://ourlil.com/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo

2008-04-19 Thread Andreas Delmelle

On Apr 18, 2008, at 21:52, Simon Pepping wrote:

Easy please. Vincent has a preference. Jeremias is OK with it, but he
is not hot about it, so he is not going to do it. Vincent did not add
the new utilities, so he is not going to do it. That leaves Andreas to
do it, or me, or ..., or it remains undone.


My thoughts on this:

a) if anyone really has a /strong/ preference to have it one way or  
the other, then I would expect a commit rather than a 'comment'. ;-)
b) if anyone states that he does not care that much, such 'comments'  
are probably never going to get him to make the necessary changes  
anyway. At most, any further insistence would irritate him slightly.  
(If he were me, at least...)


All fine by me if you're just raising the question to check if anyone  
would disagree with such a change, but as soon as the answer is:  
'Whatever, go right ahead if you prefer', then, please, take the hint  
and either shut up and live with it, or commit the changes yourself  
if it is /that/ important to you.


No amount of nagging about it is going to help anyone. Quite on the  
contrary, as we are now seeing (yet again?), if this passes a certain  
threshold, it starts to hurt productivity.


I suggest we let the matter rest here before it grows to ridiculous  
proportions --if it hasn't already... After all, it's not as if it  
concerns any Major design decisions--, and get back to coding,  
helping FOP users and everything else that /really/ matters.



Cheers

Andreas


Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo

2008-04-19 Thread Jeremias Maerki
Simon, Peter, Clay, Andreas, Chris,
thank you very much for your valuable feedback! It's reassuring to know
that I'm not totally off course.

Vincent, please keep the bug reports and other suggestions coming in the
future. But please try to treat me as a peer. I'll do the same back.
Thank you.

Have a good rest of the weekend, everyone!
Jeremias Maerki



Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo

2008-04-19 Thread Adrian Cumiskey
We each have different ideas about what quality software means and the
compromises we make with the costs associated with it.  Its  important to
try and be tolerant and respectful and give positive reinforcement to
everyone who contributes to the project.  I don't think it would harm if
*all* FOP developers would make a conscious effort to *try to be a little
more courteous* when communicating with each other - especially when you
disagree strongly on something.  You can only show someone a path, you can't
make them walk it. And email is a terrible cold medium to try and convey a
difference of opinion - things are often interpreted in a very negative way
and can escalate and turn unnecessarily nasty like it has in this situation
- its important to keep in mind what a crappy medium it is at all times.
These differences are best solved face to face in a pub over a beer - but
alas we rarely have this pleasure :(.

I'm pleased to see that most of you have not taken sides here - lets try to
keep politics out of software development as much as possible - it does
nothing but harm to a project.

Adrian.

BTW: Peter, I think you are wrong to say that Vincent is being arrogant - he
just cares about the long term health of the project and is very mindful of
the importance of making the codebase as conceptually simple and extensible
in its structure as possible - making it easier for newbies to more
effectively contribute and get involved.

On 20/04/2008, Jeremias Maerki [EMAIL PROTECTED] wrote:

 Simon, Peter, Clay, Andreas, Chris,
 thank you very much for your valuable feedback! It's reassuring to know
 that I'm not totally off course.

 Vincent, please keep the bug reports and other suggestions coming in the
 future. But please try to treat me as a peer. I'll do the same back.
 Thank you.

 Have a good rest of the weekend, everyone!

 Jeremias Maerki




-- 

Adrian.


Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo

2008-04-18 Thread Vincent Hennebert
Hi,

A few comments:

- some time ago I created a BreakUtil class in the o.a.f.util package.
  I think this class and KeepUtil should be put in the same place.
  Perhaps we could even merge them into a unique KeepsAndBreaksUtil
  class. I don’t really know what the best place would be. I put it in
  o.a.f.util because it already contains all sorts of utility classes,
  but o.a.f.layoutmgr would also make sense. WDYT?

- it would be better to create the testcases such that the rendering
  will become wrong if the feature is broken. For example, put the block
  at the bottom of the page, such that it gets deferred to the next page
  if keep is working, and split over 2 pages if keep is broken. Exactly
  like you did in block_keep-together_integers_1.xml.
  There are 2 reasons for this:
  - just because the element list looks ok doesn’t ensure that the
rendering will be fine. Actually a recent post on fop-users [1]
shows that.
  - if the generation of Knuth elements is changed somehow, all the
testcases must be adapted accordingly. I had to do that several
times when working on tables in the past months, and this is really
painful. Tests on Knuth elements should be reserved for special
situations IMO.

[1] 
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/200804.mbox/[EMAIL
 PROTECTED]

Thanks,
Vincent


 Author: jeremias
 Date: Tue Apr 15 12:18:46 2008
 New Revision: 648381

 URL: http://svn.apache.org/viewvc?rev=648381view=rev
 Log:
 First part of the implementation of stage 1 for advanced keeps (see Wiki): 
 Integer values are treated differently from always values in 
 keep-together.within-column for all block-level FOs.

split/

-- 
Vincent HennebertAnyware Technologies
http://people.apache.org/~vhennebert http://www.anyware-tech.com
Apache FOP Committer FOP Development/Consulting


Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo

2008-04-18 Thread Vincent Hennebert
Jeremias Maerki wrote:
 On 18.04.2008 12:48:53 Vincent Hennebert wrote:
 Hi,

 A few comments:

 - some time ago I created a BreakUtil class in the o.a.f.util package.
   I think this class and KeepUtil should be put in the same place.
   Perhaps we could even merge them into a unique KeepsAndBreaksUtil
   class. I don’t really know what the best place would be. I put it in
   o.a.f.util because it already contains all sorts of utility classes,
   but o.a.f.layoutmgr would also make sense. WDYT?

 Whatever.

I let you choose, but please take care of this.


 - it would be better to create the testcases such that the rendering
   will become wrong if the feature is broken. For example, put the block
   at the bottom of the page, such that it gets deferred to the next page
   if keep is working, and split over 2 pages if keep is broken. Exactly
   like you did in block_keep-together_integers_1.xml.
   There are 2 reasons for this:
   - just because the element list looks ok doesn’t ensure that the
 rendering will be fine. Actually a recent post on fop-users [1]
 shows that.

 We've had the other case, too: Rendering looked fine but the element
 list was wrong and lead to bad break decisions. I'm not sure if your
 example is a good one.

At least it shows that testing only one thing is not enough.


   - if the generation of Knuth elements is changed somehow, all the
 testcases must be adapted accordingly. I had to do that several
 times when working on tables in the past months, and this is really
 painful. Tests on Knuth elements should be reserved for special
 situations IMO.

 I'm doing unit testing here, or at least as unit testing as possible.
 What you're talking about is component testing and larger. I want to
 make sure that the element list is correct and I trust that the breaking
 algorithm does the right thing because it is already tested elsewhere. I
 completely disagree that element list test should be reserved for
 special situations. Or else this is exactly such a special situation for
 me.

Fair enough.

Vincent


-- 
Vincent HennebertAnyware Technologies
http://people.apache.org/~vhennebert http://www.anyware-tech.com
Apache FOP Committer FOP Development/Consulting


Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo

2008-04-18 Thread Jeremias Maerki
On 18.04.2008 16:51:37 Vincent Hennebert wrote:
 Jeremias Maerki wrote:
  On 18.04.2008 12:48:53 Vincent Hennebert wrote:
  Hi,
 
  A few comments:
 
  - some time ago I created a BreakUtil class in the o.a.f.util package.
I think this class and KeepUtil should be put in the same place.
Perhaps we could even merge them into a unique KeepsAndBreaksUtil
class. I don’t really know what the best place would be. I put it in
o.a.f.util because it already contains all sorts of utility classes,
but o.a.f.layoutmgr would also make sense. WDYT?
 
  Whatever.
 
 I let you choose, but please take care of this.

Whatever means: I don't care and you can fix this if it is important
to you.

snip/ 



Jeremias Maerki



Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo

2008-04-18 Thread Vincent Hennebert
Jeremias Maerki wrote:
 On 18.04.2008 16:51:37 Vincent Hennebert wrote:
 Jeremias Maerki wrote:
 On 18.04.2008 12:48:53 Vincent Hennebert wrote:
 Hi,

 A few comments:

 - some time ago I created a BreakUtil class in the o.a.f.util package.
   I think this class and KeepUtil should be put in the same place.
   Perhaps we could even merge them into a unique KeepsAndBreaksUtil
   class. I don’t really know what the best place would be. I put it in
   o.a.f.util because it already contains all sorts of utility classes,
   but o.a.f.layoutmgr would also make sense. WDYT?
 Whatever.
 I let you choose, but please take care of this.

 Whatever means: I don't care and you can fix this if it is important
 to you.

Yeah, sure, let’s all do our own mess in our own corner and everything
will be fine.

I’m not asking you to finish my work, so please don’t ask me to finish
yours. You created a class that’s closely related to another existing
one that’s somewhere else; it’s your responsibility to try and maintain
some coherence in the codebase by fixing this.

Give me any good reason for not doing this simple thing, other than that
you don’t care or you don’t have enough time, and I’m shutting up
straight away. But you can’t call for contributors on one side and not
do even the most basic cleaning behind you on the other side.


Vincent


-- 
Vincent HennebertAnyware Technologies
http://people.apache.org/~vhennebert http://www.anyware-tech.com
Apache FOP Committer FOP Development/Consulting


Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo

2008-04-18 Thread Jeremias Maerki
On 18.04.2008 19:24:05 Vincent Hennebert wrote:
 Jeremias Maerki wrote:
  On 18.04.2008 16:51:37 Vincent Hennebert wrote:
  Jeremias Maerki wrote:
  On 18.04.2008 12:48:53 Vincent Hennebert wrote:
  Hi,
 
  A few comments:
 
  - some time ago I created a BreakUtil class in the o.a.f.util package.
I think this class and KeepUtil should be put in the same place.
Perhaps we could even merge them into a unique KeepsAndBreaksUtil
class. I don’t really know what the best place would be. I put it in
o.a.f.util because it already contains all sorts of utility classes,
but o.a.f.layoutmgr would also make sense. WDYT?
  Whatever.
  I let you choose, but please take care of this.
 
  Whatever means: I don't care and you can fix this if it is important
  to you.
 
 Yeah, sure, let’s all do our own mess in our own corner and everything
 will be fine.
 
 I’m not asking you to finish my work, so please don’t ask me to finish
 yours. You created a class that’s closely related to another existing
 one that’s somewhere else; it’s your responsibility to try and maintain
 some coherence in the codebase by fixing this.
 
 Give me any good reason for not doing this simple thing, other than that
 you don’t care or you don’t have enough time, and I’m shutting up
 straight away. But you can’t call for contributors on one side and not
 do even the most basic cleaning behind you on the other side.

Ok, let's do it this way: If one other FOP committers says that this
(Vincent's idea) is something I should do, I'll do it. No discussion.
Otherwise, it's 1:1 and I won't waste my time on something I don't think
helps in any way. Remember, this is a democracy and a meritocracy here.

http://www.apache.org/foundation/how-it-works.html#meritocracy
http://www.apache.org/foundation/how-it-works.html#committers

We've had a long discussion together around this last week during
ApacheCon. IMO, you're going too far now. I increasingly feel like I'm
your bitch. Today alone I lost almost half a day because I was too angry
to work. I couldn't concentrate on what I should have been looking into.
It's ok if you point out bugs and if I fix them because the bug is one
of mine. I'm actually grateful for that. It's something else entirely if
you have some idea and expect me to do the work. For free, notabene. I
can also send you an invoice. In that case, I don't mind the additional
work.

OTOH, if I'm creating a mess here, maybe I should leave the project in
order not to damage it any more because I care about it. Or better
revert all my changes on Trunk in the last 3 years to undo the damage.
Sorry for getting sarcastic, but it's not that far off.

The other option: we could to switch to R-T-C:
http://www.apache.org/foundation/glossary.html#ReviewThenCommit
The PMC can decide to do that. That way we're always sure the community
stands behind every change. But of course, you know what that would mean
for the project.

FOP community, if you think I drifted out of line lately, please set me
straight. Vincent's voice is only one. I know this scene here is ugly
and nobody wants to waste his precious free time on participating in
fights between two people. The fight also doesn't help the project at
all. Quite the opposite. In the case of Avalon.. Anyway, I keep
finding myself in confrontations with team members from time to time. At
this time, I'm seriously questioning myself and I'm not sure if that's
just me and my thick head, if I care too much about the project, or if I
simply have more attack area because I'm one of the most active people
here. Some hints would be great (on- or off-list). Please be frank.
Thanks and my apologies for the ugly scene!


Jeremias Maerki (whose boss is Jeremias and to a certain degree the XML
Graphics PMC, but certainly not Vincent as an individual)



Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo

2008-04-18 Thread Simon Pepping
Easy please. Vincent has a preference. Jeremias is OK with it, but he
is not hot about it, so he is not going to do it. Vincent did not add
the new utilities, so he is not going to do it. That leaves Andreas to
do it, or me, or ..., or it remains undone. Fortunately, that would
not create a mess. 

Jeremias has never been in the habit of creating a mess. Nor has
Vincent. But Jeremias does not code in the manner of Vincent, nor does
Vincent in Jeremias' style. We have to live with that diversity. FOP
is that sort of project. It benefits from that diversity, because the
project has so many diverse sides to it. But the style will never be
uniform. Alas?

Simon

On Fri, Apr 18, 2008 at 09:14:01PM +0200, Jeremias Maerki wrote:
 On 18.04.2008 19:24:05 Vincent Hennebert wrote:
  Jeremias Maerki wrote:
   On 18.04.2008 16:51:37 Vincent Hennebert wrote:
   Jeremias Maerki wrote:
   On 18.04.2008 12:48:53 Vincent Hennebert wrote:
   Hi,
  
   A few comments:
  
   - some time ago I created a BreakUtil class in the o.a.f.util package.
 I think this class and KeepUtil should be put in the same place.
 Perhaps we could even merge them into a unique KeepsAndBreaksUtil
 class. I don???t really know what the best place would be. I put it 
   in
 o.a.f.util because it already contains all sorts of utility classes,
 but o.a.f.layoutmgr would also make sense. WDYT?
   Whatever.
   I let you choose, but please take care of this.
  
   Whatever means: I don't care and you can fix this if it is important
   to you.
  
 
 Ok, let's do it this way: If one other FOP committers says that this
 (Vincent's idea) is something I should do, I'll do it. No discussion.
 Otherwise, it's 1:1 and I won't waste my time on something I don't think
 helps in any way. Remember, this is a democracy and a meritocracy here.

-- 
Simon Pepping
home page: http://www.leverkruid.eu