Bob Scheifler wrote: > Geir Magnusson Jr wrote: >>> I'm extremely reluctant to start out with two podlings. >> Why? I think we are talking about two very different community dynamics. > > 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 it works out that they have different governance, then we're golden. If they work out to be the same governance, then no harm done - just bring them together. > > The community dynamics around "standards" and "an implementation" > may well be very different, but I'm not suggesting that we try to > maintain "standards" going forward, just that we try to maintain > a separation between "interface" and "implementation". Ok - that's fine. Then we just don't start the 'standards' podling? That still won't change my opinion about the problem with calling it "Apache Jini" > >> How would it work? Would you give every committer a vote on the specs >> as they were created? What is the hurdle needed to get committer >> status? Participation in both? We understand how to do code >> communities here at the ASF, and no experience in how to do spec >> creation/governance. > > Isn't a key purpose of incubation to work out the process? Well, no - it's to build healthy apache communities and oversee IP inflows. When the Incubator is figuring out new process - which is what happened with Geronimo, the first project that was all community and no code - things can be painful for that community. 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. > Is it OK if we don't have all of the answers up front? Absolutely. > Within the Sun team that created most of the specs and code > that are being proposed as the starting point for the project, > to my mind the development process for the two has pretty much > been the same. 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. > 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. > At the risk over > oversimplification, if I view a spec as "Java interface plus > javadoc", and an implementation as "Java class plus javadoc", > they are both code plus doc, amenable to the same overall process. 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. geir --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
