Geir Magnusson Jr wrote: >>For the reason I stated: I don't believe we have sufficient commitments >>from people willing and able to run a broad-based standards process. > > Wouldn't it be the same people in the code podling working in two > podlings?
If one of the podlings is for running a standards process, then no, I don't believe it would be the same people; the standards podling is likely to be close to the null set. > So by separating this, we can be sure we can do well building the code > community, and figure out the spec community along the way, if there was > interest. But by your starting sentence, you don't seem to believe > that's viable anyway. Again, I view developing specs (APIs) as distinct from running a standards process. My concerns are with the latter, not the former. > And that's a warning sign for me, right off the line, because I have > trouble seeing how the development process inside a company is going to > be similar to the somewhat chaotic dev process of an Apache project. I agree the process will be different; that wasn't my point. My point was that I don't see the development process for APIs needing to be fundamentally different from the one for implementations. >>The questions about committer votes and status >>for specs vs code seem the same as those for component A vs >>component B in a multi-component project. > > We tend not to segregate the committers. And I don't see a problem with that; it's a good thing. > You didn't just risk oversimplification, you committed an > oversimplification felony :) > > I'd argue that they are completely different in that the creation of a > spec requires different skills than implementing that spec. I don't see how requiring different skills necessarily implies requiring different development processes. - Bob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
