incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <>
Subject Re: Jini : Separate Governance and Implementation Projects
Date Tue, 15 Aug 2006 05:08:00 GMT

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?


> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message