Jeremias Maerki wrote:

> > For example, we could easily make Peter Herweg a
> > committer for the RTF libraries and renderer, but there is some
> hesitation
> > (even on my part, who thinks Peter does good work) to turn him loose in
> > layout until we know more about him, which takes time. In the
> meantime both
> > he and we must work more slowly.
> Normally, you don't just go and mess around in other people's code if
> you don't know what you're doing. I think it's a relatively weak point
> to deny someone the committership only because of that. If Peter is able
> to handle the RTF output I don't see any problem allowing him to do that.
> If he grows into the other parts, so much better. Even I have never
> messed around in layout, yet.

This seems to argue against having regulated commit access at all. IOW, on
this same principle, everyone could/should be a FOP committer. Or, perhaps
every Apache committer should be a committer on all projects. I doubt that
is what you mean, but I guess ... I don't know what you *do* mean. The point
is that if all of us had to be proficient on all Apache projects before
being given commit access to any/all of them, it would take a long time to
grow new committers. That is why FOP's monolithism is a drawback. Also, even
if you haven't messed around in layout yet, you have discussed and voted on
(IIRC) layout-related issues. There is an expectation that committers will
have a "feel" for the project as a whole, and be able to contribute ideas.

It probably sounds like I am crusading for something here, but I am not.
Jeremias's original comments about FOP's monolithism rang true in my ears.
Hearing no other proposed solutions to the problem, and seeing that mine is
deprecated, I humbly acknowledge that it is an unsolvable problem, or
perhaps no problem at all.

Victor Mote

Reply via email to