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
