Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: domain of tvhobbs@googlemail.com
 designates 209.85.213.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EBAEDA1.8020007@zeus.net.au>
References: 
 <CAEDB+kUPkGsxK7XvhHEsNsVf=8nDoUDAnU8yZ56=xBgCvRszWA@mail.gmail.com>
	<E3392E6AF5BCC94D95BB5144483090646E1B55DCF0@IE2RD2XVS551.red002.local>
	<CAEDB+kVyPx75sDV6jhcog0uamiK4Ws=nBocR3wqJv_vyU6vuVg@mail.gmail.com>
	<E3392E6AF5BCC94D95BB5144483090646E1B7D9CA5@IE2RD2XVS551.red002.local>
	<CAEDB+kUz5-O6AxbxNTni9ohrvzo5r1EDyghTDZ_Q6bz9Cpb2mA@mail.gmail.com>
	<4EB79377.5000705@qcg.nl>
	<1320691666.9644.259.camel@cameron>
	<4EB86D45.7040609@zeus.net.au>
	<4EBA52B4.7060404@qcg.nl>
	<4EBAEDA1.8020007@zeus.net.au>
Date: Thu, 10 Nov 2011 08:43:47 +0000
Message-ID: 
 <CAEDB+kW+u2A0FzdWtozE_WKZ9QJH5X_Qvxk6S6y031kmXF8bRg@mail.gmail.com>
Subject: Re: Jini Spec
From: Tom Hobbs <tvhobbs@googlemail.com>
To: dev@river.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 Peter.  But just to clarify one or two points.

> I don't think it's in our interest for PMC members to act as proxies,

"The Apache Way" expressly prohibits acting as proxies for some
external entity.  As members of the PMC we're expected/required to
always do what is best for the project.

Of course, that's not say that if you're employed by X and X would
like feature Y, we/you can't introduce feature Y.  If feature Y is
good for the project and you've got the time (company X time or
personal) to do feature Y, then go for it.  The problems start when
there are disagreements about whether feature Y should be in the
project or not.  As an individual, you might get lent on by your
employer, but you must wear your Apache PMC hat when making decisions
about the project.  That can be hard, but I don't think we're
experiencing any of that yet.

> final vote will be up to the PMC.

Indeed.  As the PMC for River, like it or not, we're custodians of
both the code and the spec.  Any given individual might not be
interested in a particular topic (notice my lack of involvement when
talking about security and internet available services ;-)  ) and
that's fine.  You might be happy churning out code and not be
interested in maintaining the spec.  Again, fine.  We just have to be
aware that if one group updates the spec, that will have a knock on
effect in the code and vice versa.  So we all need to keep at least a
shallow understanding of what the others are doing.

Regarding "the final vote".  As the project stands at the moment
committers =3D=3D PMC (as has been pointed out).  So currently, at least,
if you have commit access then you have the backing of the PMC to make
those changes.  I would probably argue that we should be more strict
with the spec updates than with code updates, since they're likely to
have more far reaching effects.  If we ever decide to grant someone
commit rights but not PMC membership then I think that's the time to
decide how we monitor changes to the code and the spec and if we
should treat those two things separately.

For my part, I'm pretty happy with how we're managing changes and
stuff so far.  We might be slow, but I think we're doing a good job!

Cheers,

Tom


On Wed, Nov 9, 2011 at 9:16 PM, Peter Firmstone <jini@zeus.net.au> wrote:
> Sim IJskes - QCG wrote:
>>
>> On 08-11-11 00:44, Peter Firmstone wrote:
>>
>>> I think a cooperatively maintained spec is good, providing motivation
>>> for ongoing compatibility among different implementations, without the
>>> burden of a standards body.
>>
>> Yes, and what at stake is here, is: are the PMC members going to act as
>> proxies for external stakeholders, who do not participate in river, or a=
re
>> we free to maintain and develop an implementation as we (PMC) see fit, w=
ith
>> only ourselfs as stakeholders. \
>
> I don't think it's in our interest for PMC members to act as proxies,
> however anyone who participates by mail list will have their ideas heard,
> final vote will be up to the PMC.
>
>>
>> A different issue (for me at least) is providing a software product, whi=
ch
>> is divided in a spec and implementation.
>
> In the past we've referred to and interpreted the spec for implementation=
.
> =A0I guess it depends on whether we code first document later, or documen=
t
> first, then code, I think in both cases, it is still useful.
>
> Some problems are difficult enough that creating a spec first produces a
> useful guide for implementation.
>
> Here are some things I'd like to make part of the spec at some point in
> future:
>
> =A01. Naming of Jini Service artifacts - Dennis has some good
> =A0 =A0 documentation for Rio, perhaps he might like to contribute back
> =A0 =A0 for the spec?
> =A02. Declarative proxy permissions, including a list of permissions in
> =A0 =A0 jar files, to inform clients at runtime of the Permissions
> =A0 =A0 required by proxy's.
> =A03. Jini 2 security extensions, Secure discovery etc.
> =A04. DNS-SRV Discovery
> =A05. Lookup Service extensions to support delayed unmarshalling,
> =A0 =A0 streaming results and local entry based logical filtering prior t=
o
> =A0 =A0 unmarshalling.
>
> We still have some very hard problems to solve relating to ClassLoaders,
> class visibility, memory isolation and codebase annotation loss, so
> distributed objects behave intuitively, Gregg works around some of these
> problems at present using MarshalledInstance's.
>
> Other interesting research areas include Codebase Services, discovered us=
ing
> DNS-SRV
>
> Cheers,
>
> Peter.
>>
>> P.S. PMC =3D=3D committer
>>
>
>