Brian Behlendorf wrote:It seems to me that any honest assessment of the merit of accepting a proposal should include a look at the code itself, if only to get a gut-check on how maintainable and evolveable that codebase might be going forward.
why? if the idea excites people but the code sucks, are we going to turn it down?
In that case, we might decide to accept a new project into the incubator for the same purpose, but decide not to accept the sucky code.
Many proposals have provided just such a link despite it not being required. Requiring it would also avoid the situation where someone says "if Apache approves it *then* I'll release the code".
why do we want to avoid this situation? what business of it is ours if the submitter wants to entrust their baby to us and only to us? we should say no when given such an expression of confidence?
I thought I explained it in the half-dozen paragraphs that followed, but I'll try it again...
It's definitely our business, because it's code that the ASF will become responsible for maintaining. Furthermore it puts a burden on the ASF to make the project successful, beyond our own intentions to do so. We aren't here to provide an open-sourcing service to companies - I don't believe we can (nor should we be expect to) look into the eyes of a company's executive and say "grant your code to us and we'll guarantee a community and a healthy project". There's an implicit promise in an arrangement like that.
Brian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
