You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Victor Mote <vi...@outfitr.com> on 2003/06/16 02:12:27 UTC
Nomination of Glen Mazza as committer
FOP Developers:
Being the greenest committer, I had hoped to defer this nomination to a more
senior developer. However, I think it is appropriate to nominate Glen Mazza
for committer status. He is knowledgeable and thoughtful, and I think it is
in the interest of the project to turn him loose so that he can keep working
without having to wait on us.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [VOTE] Nomination of Glen Mazza as committer
Posted by Jeremias Maerki <de...@greenmail.ch>.
Glen,
the request is away. An important thing for you to do is to sign and
submit the Contributor's Agreement. You can find it here:
http://incubator.apache.org/drafts/newcommitters.html along with
important additional information.
As soon as your account is created you will need to set up the SSH
tunnel for CVS access. If you have trouble, just yell!
Welcome aboard!
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [VOTE] Nomination of Glen Mazza as committer
Posted by Glen Mazza <gr...@yahoo.com>.
Jeremias,
Please forward off the following:
Thanks,
Glen
Full Name: Glen Mazza
Preferred Userid: gmazza
Forwarding email address: glenmazza@yahoo.com
"Karma": just xml-fop
--- Jeremias Maerki <de...@greenmail.ch> wrote:
> Can do.
>
> Here's the new account request form that we need to
> fill:
> New account request form:
>
> To: root@apache.org
> Cc: pmc@<project>.apache.org,
> newcommitters@email.address
> Subject: Apache account request
>
> Full name: ...
> Preferred userid: ...
> Forwarding email address: ...
>
> Requested karma: <project>[/<subproject>]
> ...
>
> [Vote: link to mail archive for
> PMC bookkeeping]
>
>
> On 18.06.2003 10:21:42 Christian Geisert wrote:
> > Clearly enough +1 and no -1, congratulations Glen!
> >
> > According to http://www.apache.org/dev/pmc.html
> the account
> > request should be handled by the PMC - so Jeremias
> or Peter
> > would you please take care of this?
>
>
> Jeremias Maerki
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> fop-dev-unsubscribe@xml.apache.org
> For additional commands, email:
> fop-dev-help@xml.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [VOTE] Nomination of Glen Mazza as committer
Posted by Jeremias Maerki <de...@greenmail.ch>.
Can do.
Here's the new account request form that we need to fill:
New account request form:
To: root@apache.org
Cc: pmc@<project>.apache.org, newcommitters@email.address
Subject: Apache account request
Full name: ...
Preferred userid: ...
Forwarding email address: ...
Requested karma: <project>[/<subproject>] ...
[Vote: link to mail archive for PMC bookkeeping]
On 18.06.2003 10:21:42 Christian Geisert wrote:
> Clearly enough +1 and no -1, congratulations Glen!
>
> According to http://www.apache.org/dev/pmc.html the account
> request should be handled by the PMC - so Jeremias or Peter
> would you please take care of this?
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [VOTE] Nomination of Glen Mazza as committer
Posted by Christian Geisert <ch...@isu-gmbh.de>.
Christian Geisert schrieb:
> Oleg Tkachenko schrieb:
>
>> Jeremias Maerki wrote:
>>
>>> I agree, so +1 from me.
>>
>> Here is my +1.
>
> +1
Clearly enough +1 and no -1, congratulations Glen!
According to http://www.apache.org/dev/pmc.html the account
request should be handled by the PMC - so Jeremias or Peter
would you please take care of this?
Glen, what userid would you like?
Some infos for the start: http://www.apache.org/dev/committers.html
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [VOTE] Nomination of Glen Mazza as committer
Posted by Christian Geisert <ch...@isu-gmbh.de>.
Oleg Tkachenko schrieb:
> Jeremias Maerki wrote:
>
>> I agree, so +1 from me.
>
>
> Here is my +1.
+1
<English>Welcome Glen</English>
<German>
Gut so, jetzt müssen wir seine Patches nicht mehr bearbeiten.
</German>
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [VOTE] Nomination of Glen Mazza as committer
Posted by Oleg Tkachenko <ol...@multiconn.com>.
Jeremias Maerki wrote:
> I agree, so +1 from me.
Here is my +1.
--
Oleg Tkachenko
http://www.tkachenko.com/blog
Multiconn Technologies, Israel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [VOTE] Nomination of Glen Mazza as committer
Posted by Jeremias Maerki <de...@greenmail.ch>.
I agree, so +1 from me.
On 16.06.2003 02:12:27 Victor Mote wrote:
> Being the greenest committer, I had hoped to defer this nomination to a more
> senior developer. However, I think it is appropriate to nominate Glen Mazza
> for committer status. He is knowledgeable and thoughtful, and I think it is
> in the interest of the project to turn him loose so that he can keep working
> without having to wait on us.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Nomination of Glen Mazza as committer
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
> Sent: June 16, 2003 5:46 PM
> To: fop-dev@xml.apache.org
> Subject: Re: Nomination of Glen Mazza as committer
>
>
> Victor Mote wrote:
> > Being the greenest committer, I had hoped to defer this
> nomination to a more
> > senior developer. However, I think it is appropriate to
> nominate Glen Mazza
> > for committer status. He is knowledgeable and thoughtful, and I
> think it is
> > in the interest of the project to turn him loose so that he can
> keep working
> > without having to wait on us.
>
> +1
And also +1.
Arved
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Nomination of Glen Mazza as committer
Posted by Glen Mazza <gr...@yahoo.com>.
Any committer from Chicago? A +6 or +7 would be
really fantastic right now!!! ;)
Thanks, virtual team, for all the endorsements. I am
painfully aware that others had to contribute far more
and for a longer time to become committers--I'll work
on reducing that delta over the upcoming weekends!
Regards,
Glen
--- "J.Pietschmann" <j3...@yahoo.de> wrote:
>
> +1
>
> J.Pietschmann
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Nomination of Glen Mazza as committer
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Victor Mote wrote:
> Being the greenest committer, I had hoped to defer this nomination to a more
> senior developer. However, I think it is appropriate to nominate Glen Mazza
> for committer status. He is knowledgeable and thoughtful, and I think it is
> in the interest of the project to turn him loose so that he can keep working
> without having to wait on us.
+1
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Comments
Posted by "Peter B. West" <pb...@powerup.com.au>.
J.Pietschmann wrote:
> Peter B. West wrote:
>
>> I recall, however, that it took me a year to gain that status, a year
>> during which I wrote a considerable amount of code which I maintained
>> in my ISP account. My crime was that I did not toe the Party line. I
>> hope those days are gone, and that, should a developer happen along
>> who contributes to alt.design, and expresses a desire to continue to
>> work on it, he or she will be granted committer status with the now
>> customary alacrity.
>
>
> Sorry, I don't see much value in using pull parsing instead of
> push parsing either. Now if you could get footnote separators
> to appear in HEAD, or TR14 line breaking, or side floats...
So we shall disagree. That is not my point. Is disagreement allowed?
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Comments (was: Re: Nomination of Glen Mazza as committer)
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Peter B. West wrote:
> I recall, however, that it took me a year to gain that status, a year
> during which I wrote a considerable amount of code which I maintained in
> my ISP account. My crime was that I did not toe the Party line. I hope
> those days are gone, and that, should a developer happen along who
> contributes to alt.design, and expresses a desire to continue to work on
> it, he or she will be granted committer status with the now customary
> alacrity.
Sorry, I don't see much value in using pull parsing instead of
push parsing either. Now if you could get footnote separators
to appear in HEAD, or TR14 line breaking, or side floats...
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Nomination of Glen Mazza as committer
Posted by "Peter B. West" <pb...@powerup.com.au>.
Glen,
I did notice your interest, and I appreciate it.
Peter
Glen Mazza wrote:
> Peter--I've been *trying* to contribute to your
> alt.design--I respond as best I can to your postings.
>
> Many of us (but by no means all) are just not yet in
> your order-of-magnitude of knowledge yet...
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Nomination of Glen Mazza as committer
Posted by Glen Mazza <gr...@yahoo.com>.
Peter--I've been *trying* to contribute to your
alt.design--I respond as best I can to your postings.
Many of us (but by no means all) are just not yet in
your order-of-magnitude of knowledge yet...
Glen
--- "Peter B. West" <pb...@powerup.com.au> wrote:
> and that, should a developer
> happen along who
> contributes to alt.design, and expresses a desire to
> continue to work on
> it, he or she will be granted committer status with
> the now customary
> alacrity.
>
> Peter
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
alt-design merits
Posted by "Peter B. West" <pb...@powerup.com.au>.
Peter B. West wrote:
>
> If I have not answered your question, yell out. I am quite happy to
> keep on at this until you at least understand my thinking on this, even
> if you don't agree with it.
But I will be keeping on with it tomorrow, as it is very late here.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: alt-design merits (WAS: Nomination of Glen Mazza as committer)
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor,
Trying to answer your latest questions on this topic has absorbed a deal
of my time, exposed a contradiction in my thinking, and made me think
through in more detail some of the fuzzy bits. I am still working on
it, and I will get back to you. Thanks for the interrogation.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: alt-design merits (WAS: Nomination of Glen Mazza as committer)
Posted by Victor Mote <vi...@outfitr.com>.
Peter B. West wrote:
> They can. They must. But then what happens to the idea that the FO
> tree can be processed and refined before the layout occurs? If you are
The pieces that can be processed are. The pieces that cannot are deferred.
> tree can be processed and refined before the layout occurs? If you are
> going to defer the resolution, why not defer the parsing as well?
Because to simple minds like mine, they seem like easily separable tasks for
which there is no benefit to mixing. More to the point of this conversation,
if you can complete the parsing before starting layout, why not?
> Marker resolution requires the merging of the fo:static-content subtree
> (encountered *before* the corresponding fo:flow) with fo:marker subtrees
> which can only be determined as pages are laid out. Furthermore, this
> process may repeat with *different* fo:marker subtrees being attached at
> the same fo:retrieve-marker point in the static-content.
OK, but this doesn't help me understand how pull parsing is superior to
building an FO Tree.
> With pull parsing, events are extracted from a parsing event buffer *as
> required*. In general, this will occur "synchronously", but need not.
By way of comparison, with the FO Tree, information is extracted from the
tree *as required*. Again, I don't see the benefit.
> The stream of static-content parsing events can be stashed away, the
> stream of fo:marker subtree events can be stashed away somewhere else,
Why not "stash away" in an FO Tree?
> and the process of resolving the FO tree need never know that it is in
> fact reading an "asynchronous" stream of parser events in which
> fo:marker streams are attached by sleight-of-hand in place of the
> fo:retrieve marker dynamically and transparently, and that this parsing
> is happening after the event - well after the static-content was first
> encountered, and after the region-body has been laid out. Furthermore,
> it can be "rewound" and repeated for as long as new pages with new
> fo.marker retrievals are required.
I do not see the advantage of using sleight-of-hand events over a data
structure.
> "Synchronous" and "asynchronous" are relative terms here. It's all
> asynchronous, in the sense that the SAX component simply creates parse
> events and sticks them in a producer/consumer buffer.
>
> The other problem is percentage lengths, where the percentage is defined
> against an enclosing area dimension. Doesn't it make sense to create
> the area before you even look at the FOs which will fill it? Creating
Not to my way of thinking (although I have struggled with this a bit). In
general, XSL-FO 1.0 content drives the layout, not the other way around. (If
you have Dave Pawson's book, see the last section of Chapter 2.) IMO, the
percentage problem that you mention is an exception to this rule that can be
handled without a redesign of the whole system. How can you create an area
for a block without knowing its "span" attribute? (BTW, I think the redesign
stumbles here as well).
> the area also creates the context for the resolution of percentages. In
> the difficult cases where the area dimension is initially indeterminate,
> the unresolvable percentage can at least be immediately "attached" to
> the area dimension whose resolution will in turn, resolve the
> percentage. In most cases, however, the resolution will be immediate.
Is this not implemented/implementable in redesign?
> This approach, of having the containing area in place before parsing the
> contained FO subtree, is easy to implement with pull parsing, driven by
> the *areas*.
If it were a good thing, it seems at least as easy to implement using the FO
Tree.
> If I have not answered your question, yell out. I am quite happy to
> keep on at this until you at least understand my thinking on this, even
> if you don't agree with it.
In addition to not following the benefits, I see the following apparent
drawbacks, which I would be glad to have you address:
1. Less modularity
2. More complex design
I wanted to add "less flexible", because it would seem to restrict our
ability to make the layout pluggable. However, that is probably not true,
but that line of thinking led to an interesting thought. If pluggable layout
works, then perhaps your whole pull-parsing logic could be implemented
entirely as an implementation of LayoutStrategy. For this purpose, it would
work similarly to our Structured output concepts (MIF, RTF), in that no FO
Tree would be built, but the SAX events are passed through. You could then
do with them whatever you wish, sychronously or asynchronously,
right-brained or left-brained, Northern Hemisphere or Southern :-) Is that
worth exploring? Can your stuff use the general Area Tree model?
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: alt-design merits (WAS: Nomination of Glen Mazza as committer)
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor Mote wrote:
> Peter B. West wrote:
>
>
>>Which modules? I'm not sure what you mean. The modularity of area
>>processing? The Rec gives an utterly spurious view of this. It has
>>been misleading developers since the drafts were first published, and
>>giving the impression that things can be neatly modularised. Some of
>>the persistent difficulties of design arise from this misunderstanding.
>> However, I may be misreading you here. What modules do you
>>have in mind?
>
>
> All right, educate me please. (I have read your doc and don't get it). In as
> simple terms as possible (for my simple mind), why can't markers defer the
> resolution of their properties until layout time?
They can. They must. But then what happens to the idea that the FO
tree can be processed and refined before the layout occurs? If you are
going to defer the resolution, why not defer the parsing as well?
Marker resolution requires the merging of the fo:static-content subtree
(encountered *before* the corresponding fo:flow) with fo:marker subtrees
which can only be determined as pages are laid out. Furthermore, this
process may repeat with *different* fo:marker subtrees being attached at
the same fo:retrieve-marker point in the static-content.
With pull parsing, events are extracted from a parsing event buffer *as
required*. In general, this will occur "synchronously", but need not.
The stream of static-content parsing events can be stashed away, the
stream of fo:marker subtree events can be stashed away somewhere else,
and the process of resolving the FO tree need never know that it is in
fact reading an "asynchronous" stream of parser events in which
fo:marker streams are attached by sleight-of-hand in place of the
fo:retrieve marker dynamically and transparently, and that this parsing
is happening after the event - well after the static-content was first
encountered, and after the region-body has been laid out. Furthermore,
it can be "rewound" and repeated for as long as new pages with new
fo.marker retrievals are required.
"Synchronous" and "asynchronous" are relative terms here. It's all
asynchronous, in the sense that the SAX component simply creates parse
events and sticks them in a producer/consumer buffer.
The other problem is percentage lengths, where the percentage is defined
against an enclosing area dimension. Doesn't it make sense to create
the area before you even look at the FOs which will fill it? Creating
the area also creates the context for the resolution of percentages. In
the difficult cases where the area dimension is initially indeterminate,
the unresolvable percentage can at least be immediately "attached" to
the area dimension whose resolution will in turn, resolve the
percentage. In most cases, however, the resolution will be immediate.
This approach, of having the containing area in place before parsing the
contained FO subtree, is easy to implement with pull parsing, driven by
the *areas*.
If I have not answered your question, yell out. I am quite happy to
keep on at this until you at least understand my thinking on this, even
if you don't agree with it.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
alt-design merits (WAS: Nomination of Glen Mazza as committer)
Posted by Victor Mote <vi...@outfitr.com>.
Peter B. West wrote:
> Which modules? I'm not sure what you mean. The modularity of area
> processing? The Rec gives an utterly spurious view of this. It has
> been misleading developers since the drafts were first published, and
> giving the impression that things can be neatly modularised. Some of
> the persistent difficulties of design arise from this misunderstanding.
> However, I may be misreading you here. What modules do you
> have in mind?
All right, educate me please. (I have read your doc and don't get it). In as
simple terms as possible (for my simple mind), why can't markers defer the
resolution of their properties until layout time?
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Nomination of Glen Mazza as committer
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor and fopdevs,
See below...
Victor Mote wrote:
> Peter B. West wrote:
>
>
>>As to the necessary conditions for committer status, "Shall we take that
>>as read, darling?"* The question remains, "If a another developer
>>happens along who 1) is persuaded that alt.design is worthwhile, and 2)
>>sees the existing properties code as a working implementation that is
>>better, and 3) wants to work on alt.design more or less exclusively,
>>will he/she be admitted to committer status with the - all other things
>>being equal - now customary alacrity?"
>>
>>Will those existing committers who are not interested in alt.design
>>allow it to flourish in the (unlikely) event that it attracts the
>>interest of other developers, or will the Party line, necessary as that
>>may be considered, dictate the such a development be resisted?
>
>
> I have exactly one vote on such matters, so I can't speak for the whole, but
> as far as I am concerned, developers such as you describe are more than
> welcome to join the party. In the event that alt-design remains on a branch,
> I don't think any reasonable person could object. At the point in time that
> we contemplate merging to the trunk, we need to come to an agreement. In the
> unlikely event that we can't come to an agreement, we always have the option
> to fork the project. My purpose here is to avoid that if possible.
>
> BTW, I hope this isn't a Peter-vs.-Victor thing.
Absolutely not. This is a question for all of the existing committers.
Your response above is exactly the one I would hope to see from
everyone. Incidentally, the project is already de facto forked - the
purpose of integration is to bring the benefits of alt.design into the
main redesign.
> For example, I know there
> are opportunities to use less memory and more speed (which you report in
> alt-design) in the FO tree creation. If memory serves, we are storing the
> URL for the fo: namespace in every FONode object, which should be replaced
> by an integer pointing into a table. I am very open to being educated, but I
> think it is fair to say that I am not persuaded on all of it yet, and I
> think the burden of proof lies heavily on you. Unless pull parsing is an
> integral part of the whole, I think the alt-design changes will be best
> swallowed in smaller pieces.
alt.design is a complete rewrite of the front end. It could possibly be
broken up and rejigged to use a standard SAX approach, but that would
require major surgery, and would obviate a great deal of the advantage
of doing away with the design convolution which is imposed by SAX.
There is no great design rationale in the basics of the current approach
to FO tree parsing. It is that way because it is obliged to be by SAX.
SAX imposes itself on design, unless it is forcibly restrained, and
that imposition will, IMO, always be to the detriment of the design of
complex systems with a well-understood structure to their data.
Clearly, that is a view that is not shared here, but it is one, which, I
believe, has been and is being debated at length elsewhere. Andy
Clark's NekoPull variations on Xerces XNI are an attempt to provide a
pull alternative for Open Source parsing. It seems unproductive to try
to debate the issue here; one either takes to it or one doesn't.
> Also, if pull parsing can be implemented in a pluggable, configurable way
> (ie. choose either push parsing or pull parsing at runtime), it will have a
> much better chance of being accepted. My understanding of it is that it has
> a pervasive effect, making separation between the modules more difficult
> instead of less. IMO, absent a /significant/ benefit that cannot be achieved
> some other way, this would be a deal-killer.
Which modules? I'm not sure what you mean. The modularity of area
processing? The Rec gives an utterly spurious view of this. It has
been misleading developers since the drafts were first published, and
giving the impression that things can be neatly modularised. Some of
the persistent difficulties of design arise from this misunderstanding.
However, I may be misreading you here. What modules do you have in mind?
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Nomination of Glen Mazza as committer
Posted by Victor Mote <vi...@outfitr.com>.
Peter B. West wrote:
> As to the necessary conditions for committer status, "Shall we take that
> as read, darling?"* The question remains, "If a another developer
> happens along who 1) is persuaded that alt.design is worthwhile, and 2)
> sees the existing properties code as a working implementation that is
> better, and 3) wants to work on alt.design more or less exclusively,
> will he/she be admitted to committer status with the - all other things
> being equal - now customary alacrity?"
>
> Will those existing committers who are not interested in alt.design
> allow it to flourish in the (unlikely) event that it attracts the
> interest of other developers, or will the Party line, necessary as that
> may be considered, dictate the such a development be resisted?
I have exactly one vote on such matters, so I can't speak for the whole, but
as far as I am concerned, developers such as you describe are more than
welcome to join the party. In the event that alt-design remains on a branch,
I don't think any reasonable person could object. At the point in time that
we contemplate merging to the trunk, we need to come to an agreement. In the
unlikely event that we can't come to an agreement, we always have the option
to fork the project. My purpose here is to avoid that if possible.
BTW, I hope this isn't a Peter-vs.-Victor thing. For example, I know there
are opportunities to use less memory and more speed (which you report in
alt-design) in the FO tree creation. If memory serves, we are storing the
URL for the fo: namespace in every FONode object, which should be replaced
by an integer pointing into a table. I am very open to being educated, but I
think it is fair to say that I am not persuaded on all of it yet, and I
think the burden of proof lies heavily on you. Unless pull parsing is an
integral part of the whole, I think the alt-design changes will be best
swallowed in smaller pieces.
Also, if pull parsing can be implemented in a pluggable, configurable way
(ie. choose either push parsing or pull parsing at runtime), it will have a
much better chance of being accepted. My understanding of it is that it has
a pervasive effect, making separation between the modules more difficult
instead of less. IMO, absent a /significant/ benefit that cannot be achieved
some other way, this would be a deal-killer.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Nomination of Glen Mazza as committer
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor,
As to the necessary conditions for committer status, "Shall we take that
as read, darling?"* The question remains, "If a another developer
happens along who 1) is persuaded that alt.design is worthwhile, and 2)
sees the existing properties code as a working implementation that is
better, and 3) wants to work on alt.design more or less exclusively,
will he/she be admitted to committer status with the - all other things
being equal - now customary alacrity?"
Will those existing committers who are not interested in alt.design
allow it to flourish in the (unlikely) event that it attracts the
interest of other developers, or will the Party line, necessary as that
may be considered, dictate the such a development be resisted?
Peter
* John Cleese, in "The Meaning of Life"
Victor Mote wrote:
> Peter B. West wrote:
>
>
>>plus comments. I am happy to see new committers come into the project.
>> I recall, however, that it took me a year to gain that status, a year
>>during which I wrote a considerable amount of code which I maintained in
>>my ISP account. My crime was that I did not toe the Party line. I hope
>>those days are gone, and that, should a developer happen along who
>>contributes to alt.design, and expresses a desire to continue to work on
>>it, he or she will be granted committer status with the now customary
>>alacrity.
>
>
> I'm going to respond to your (prior) emails in turn, but this one deserves
> special attention. It is not my intention to institute or encourage a policy
> of "customary alacrity", but rather "timely attention". If Bill Joy or James
> Duncan Davidson asked to be made committers on this project, I would vote
> for it today. I have an 11-year old son who wants to be a Java programmer,
> and he'll have to wait a bit before getting my vote. I wasn't around for the
> year of which you speak, and I don't know where you fall on that continuum.
> My only point is that the timing for Glen seems appropriate.
>
> With regard to a Party Line, please allow me to briefly philosophize. Civil
> societies (of which FOP development can be considered one) have both
> centrifugal and centripetal forces at work. In general, the centrifugal
> forces are that we each like to have things done our way, and the
> centripetal forces are an acknowledgement that we are unable to achieve the
> goal without help from others. If one person were able to complete a project
> the size of FOP, we would all be better off to delegate that task to that
> one person and let them do the job. We know that can't happen. We also know
> that if Jeremias is headed north and I am headed south, a lot of energy is
> expended, but not much progress is made. So, yes, there is a Party Line, a
> common consensus about how to get where we want to go. No, I do not want FOP
> rewritten in Fortran. No, I do not want FOP to output everything to RTF,
> then convert it to PDF. And no, frankly, I don't want the layout process
> pulling the parsing (until I can be persuaded of a substantial benefit).
> Yes, there is a Party Line, and there must be. I am at odds with certain
> pieces of it. In the long run, I will either 1) persuade a change in it, 2)
> show a working implementation that is better, 3) be persuaded myself to
> change, 4) live with it the way it is because it is better than
> alternatives, or 5) go away and do something else. That is the nature of
> civil societies. As long as #5 is an option, there is nothing tyrannical
> about it.
>
> I will address the merits of your proposals in separate messages on those
> threads. In the meantime, AFAIK, everyone on this team values your efforts.
> I am sure that no one is intentionally slighting you. I have about 20 hours
> a week to spend on FOP, and for my feeble brain that is just not enough
> bandwidth to comprehensively evaluate every proposal on the table.
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Nomination of Glen Mazza as committer
Posted by Victor Mote <vi...@outfitr.com>.
Peter B. West wrote:
> plus comments. I am happy to see new committers come into the project.
> I recall, however, that it took me a year to gain that status, a year
> during which I wrote a considerable amount of code which I maintained in
> my ISP account. My crime was that I did not toe the Party line. I hope
> those days are gone, and that, should a developer happen along who
> contributes to alt.design, and expresses a desire to continue to work on
> it, he or she will be granted committer status with the now customary
> alacrity.
I'm going to respond to your (prior) emails in turn, but this one deserves
special attention. It is not my intention to institute or encourage a policy
of "customary alacrity", but rather "timely attention". If Bill Joy or James
Duncan Davidson asked to be made committers on this project, I would vote
for it today. I have an 11-year old son who wants to be a Java programmer,
and he'll have to wait a bit before getting my vote. I wasn't around for the
year of which you speak, and I don't know where you fall on that continuum.
My only point is that the timing for Glen seems appropriate.
With regard to a Party Line, please allow me to briefly philosophize. Civil
societies (of which FOP development can be considered one) have both
centrifugal and centripetal forces at work. In general, the centrifugal
forces are that we each like to have things done our way, and the
centripetal forces are an acknowledgement that we are unable to achieve the
goal without help from others. If one person were able to complete a project
the size of FOP, we would all be better off to delegate that task to that
one person and let them do the job. We know that can't happen. We also know
that if Jeremias is headed north and I am headed south, a lot of energy is
expended, but not much progress is made. So, yes, there is a Party Line, a
common consensus about how to get where we want to go. No, I do not want FOP
rewritten in Fortran. No, I do not want FOP to output everything to RTF,
then convert it to PDF. And no, frankly, I don't want the layout process
pulling the parsing (until I can be persuaded of a substantial benefit).
Yes, there is a Party Line, and there must be. I am at odds with certain
pieces of it. In the long run, I will either 1) persuade a change in it, 2)
show a working implementation that is better, 3) be persuaded myself to
change, 4) live with it the way it is because it is better than
alternatives, or 5) go away and do something else. That is the nature of
civil societies. As long as #5 is an option, there is nothing tyrannical
about it.
I will address the merits of your proposals in separate messages on those
threads. In the meantime, AFAIK, everyone on this team values your efforts.
I am sure that no one is intentionally slighting you. I have about 20 hours
a week to spend on FOP, and for my feeble brain that is just not enough
bandwidth to comprehensively evaluate every proposal on the table.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Nomination of Glen Mazza as committer
Posted by "Peter B. West" <pb...@powerup.com.au>.
+1
plus comments. I am happy to see new committers come into the project.
I recall, however, that it took me a year to gain that status, a year
during which I wrote a considerable amount of code which I maintained in
my ISP account. My crime was that I did not toe the Party line. I hope
those days are gone, and that, should a developer happen along who
contributes to alt.design, and expresses a desire to continue to work on
it, he or she will be granted committer status with the now customary
alacrity.
Peter
Victor Mote wrote:
> FOP Developers:
>
> Being the greenest committer, I had hoped to defer this nomination to a more
> senior developer. However, I think it is appropriate to nominate Glen Mazza
> for committer status. He is knowledgeable and thoughtful, and I think it is
> in the interest of the project to turn him loose so that he can keep working
> without having to wait on us.
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Nomination of Glen Mazza as committer
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Lundi, 16 juin 2003, à 02:12 Europe/Zurich, Victor Mote a écrit :
> ...However, I think it is appropriate to nominate Glen Mazza
> for committer status....
+1, welcome!
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org