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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to