Re: Implementation of unreleased spec and community

[Guillaume Nodet]

No, not at all, and I hope my actions are not taken against any one either.
I had to mention you explicitly in order to make things more clear, sorry
about that.
Though I really do want to make sure the process more straight and make
sure it's done fairly and by the rules.

2017-01-20 14:20 GMT+01:00 Raymond Auge :

> Apparently I've severely offended you Guillaume. If so I sincerely
> apologize. That was never my intention.
>
> Sincerely,
> - Ray
>
> On Jan 20, 2017 5:42 AM, "Guillaume Nodet"  wrote:
>
> 2017-01-20 11:26 GMT+01:00 Neil Bartlett :
>
> >
> > > On 20 Jan 2017, at 10:12, Guillaume Nodet  wrote:
> > >
> > > 2017-01-20 10:58 GMT+01:00 Guillaume Nodet  gno...@apache.org>>:
> > >
> > >>
> > >>
> > >> 2017-01-19 19:36 GMT+01:00 Timothy Ward :
> > >>
> > >>> At this point I’d also like to re-affirm that the OSGi RFC documents
> > are
> > >>> public, and that there is a public feedback mechanism for RFC bugs.
> As
> > the
> > >>> holder of the pen for Transaction Control, the JAX-RS whiteboard, and
> > the
> > >>> JPA service updates I can truthfully say that community discussion
> and
> > >>> feedback has influenced the direction of those RFCs/specifications,
> not
> > >>> just the converter.
> > >>>
> > >>> As David says below, you can gain increased control over the
> direction
> > of
> > >>> things anywhere by becoming a member/committer/employee. Committers
> in
> > >>> Apache Aries have ample opportunity to review and discuss the many
> > >>> implementations built there, just as they do in Felix. This right
> > applies
> > >>> both before and after the release of the specification. What Apache
> > >>> Committers can’t do is make changes to an OSGi RFC/spec, for that
> they
> > need
> > >>> to lobby an OSGi member.
> > >>
> > >>
> > >> I have no problems with the above.
> > >>
> > >>
> > >>> This is exactly the same for a committer in Eclipse, on Github, or in
> a
> > >>> private company, so it leaves Apache committers just as equal as
> > everyone
> > >>> else.
> > >>
> > >>
> > >> I don't care about how Eclipse or Github project are operated.  We're
> > >> talking about Apache projects and there are rules.  One of them is
> that
> > >> committers are considered equal.
> > >>
> > >>
> > >>> The main difference here is that there are a lot of OSGi members who
> > >>> believe in Apache, and therefore contribute as committers. Are we
> > really
> > >>> saying that those committers should be disallowed because they are
> OSGi
> > >>> members and therefore have “more power”?
> > >>>
> > >>
> > >> Not disallowed, but yes, they should not do something within the ASF
> > that
> > >> other committers who are not OSGi members can't do.
> > >> So to be clear: if any committer want to work on an implementation of
> an
> > >> RFC or spec from the OSGi Alliance, that's fine, whether they are OSGi
> > >> members or not.
> > >> If an OSGi member want to work on spec design within the ASF bounds, I
> > >> think that's not fine.   In particular, if someone propose to develop
> > some
> > >> code to implement an RFC when the API from the developped and later
> > >> introduced back into the RFC document, I think that's definitely spec
> > work,
> > >> and should not be done within the RFC.
> > >>
> > >> To be crystal clear, I have a problem with Ray willing to bring code
> for
> > >> implementing rfc-193 in Aries, when the code that he wants to bring
> > >> contains lots of things that are not reflected in the RFC document and
> > the
> > >> opposite.  Ray and David explained that the RFC document will be
> > updated in
> > >> the coming weeks to reflect those changes.  This is definitely spec
> > work,
> > >> and that's fine, but I don't think it should happen at Apache.  Again,
> > it's
> > >> a timing problem wrt to changes in the document and changes in the
> code
> > :
> > >> if the code is changes first by the spec lead, and later validated on
> > >> during OSGi meetings and later integrated into the spec document and
> > made
> > >> public, I definitely see that as spec work, not as building an
> > >> implementation, and imho this is unfair to other committers because it
> > does
> > >> not follow the ASF rules.  It's certainly open source, but not the
> > Apache
> > >> way.
> > >>
> > >
> > > And btw, even from a legal ASF pov, I'm not sure how things hold.
> People
> > > are writing code copyrighted to the OSGi Alliance directly in the ASF…
> >
> >
> > And when *you* write code in the ASF, you own the copyright to that code.
> > Apache does not require or expect that copyright ownership of the code is
> > transferred to the ASF, only that it is licensed under the terms of the
> > ASL. The fact that OSGi Alliance may be the copyright holder of some code
> > does not present any problems.
> >
> > Though maybe you shouldn’t seek legal advice on a developer mailing list
> > ;-)

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

2017-01-20 14:49 GMT+01:00 Richard S. Hall :

> On 1/20/17 05:42 , Guillaume Nodet wrote:
>
>> 2017-01-20 11:26 GMT+01:00 Neil Bartlett :
>>
>> On 20 Jan 2017, at 10:12, Guillaume Nodet  wrote:

 2017-01-20 10:58 GMT+01:00 Guillaume Nodet >>
>>> gno...@apache.org>>:
>>>

> 2017-01-19 19:36 GMT+01:00 Timothy Ward :
>
> At this point I’d also like to re-affirm that the OSGi RFC documents
>>
> are
>>>
 public, and that there is a public feedback mechanism for RFC bugs. As
>>
> the
>>>
 holder of the pen for Transaction Control, the JAX-RS whiteboard, and
>>
> the
>>>
 JPA service updates I can truthfully say that community discussion and
>> feedback has influenced the direction of those RFCs/specifications,
>> not
>> just the converter.
>>
>> As David says below, you can gain increased control over the direction
>>
> of
>>>
 things anywhere by becoming a member/committer/employee. Committers in
>> Apache Aries have ample opportunity to review and discuss the many
>> implementations built there, just as they do in Felix. This right
>>
> applies
>>>
 both before and after the release of the specification. What Apache
>> Committers can’t do is make changes to an OSGi RFC/spec, for that they
>>
> need
>>>
 to lobby an OSGi member.
>>
>
> I have no problems with the above.
>
>
> This is exactly the same for a committer in Eclipse, on Github, or in a
>> private company, so it leaves Apache committers just as equal as
>>
> everyone
>>>
 else.
>>
>
> I don't care about how Eclipse or Github project are operated.  We're
> talking about Apache projects and there are rules.  One of them is that
> committers are considered equal.
>
>
> The main difference here is that there are a lot of OSGi members who
>> believe in Apache, and therefore contribute as committers. Are we
>>
> really
>>>
 saying that those committers should be disallowed because they are OSGi
>> members and therefore have “more power”?
>>
>> Not disallowed, but yes, they should not do something within the ASF
>
 that
>>>
 other committers who are not OSGi members can't do.
> So to be clear: if any committer want to work on an implementation of
> an
> RFC or spec from the OSGi Alliance, that's fine, whether they are OSGi
> members or not.
> If an OSGi member want to work on spec design within the ASF bounds, I
> think that's not fine.   In particular, if someone propose to develop
>
 some
>>>
 code to implement an RFC when the API from the developped and later
> introduced back into the RFC document, I think that's definitely spec
>
 work,
>>>
 and should not be done within the RFC.
>
> To be crystal clear, I have a problem with Ray willing to bring code
> for
> implementing rfc-193 in Aries, when the code that he wants to bring
> contains lots of things that are not reflected in the RFC document and
>
 the
>>>
 opposite.  Ray and David explained that the RFC document will be
>
 updated in
>>>
 the coming weeks to reflect those changes.  This is definitely spec
>
 work,
>>>
 and that's fine, but I don't think it should happen at Apache.  Again,
>
 it's
>>>
 a timing problem wrt to changes in the document and changes in the code
>
 :
>>>
 if the code is changes first by the spec lead, and later validated on
> during OSGi meetings and later integrated into the spec document and
>
 made
>>>
 public, I definitely see that as spec work, not as building an
> implementation, and imho this is unfair to other committers because it
>
 does
>>>
 not follow the ASF rules.  It's certainly open source, but not the
>
 Apache
>>>
 way.
>
> And btw, even from a legal ASF pov, I'm not sure how things hold.
 People
 are writing code copyrighted to the OSGi Alliance directly in the ASF…

>>>
>>> And when *you* write code in the ASF, you own the copyright to that code.
>>> Apache does not require or expect that copyright ownership of the code is
>>> transferred to the ASF, only that it is licensed under the terms of the
>>> ASL. The fact that OSGi Alliance may be the copyright holder of some code
>>> does not present any problems.
>>>
>>> Though maybe you shouldn’t seek legal advice on a developer mailing list
>>> ;-)
>>>
>>> Well, the code does not seem to comply to the ASF rules at leat:
>>https://www.apache.org/legal/src-headers.html
>>
>>
>> 1. This section refers only to works submitted directly to the ASF by
>> the copyright owner or owner's agent.
>> 2. This section refers only to works submitted directly to the ASF by

Re: Implementation of unreleased spec and community

[Richard S. Hall]

On 1/20/17 05:42 , Guillaume Nodet wrote:

2017-01-20 11:26 GMT+01:00 Neil Bartlett :


On 20 Jan 2017, at 10:12, Guillaume Nodet  wrote:

2017-01-20 10:58 GMT+01:00 Guillaume Nodet >:


2017-01-19 19:36 GMT+01:00 Timothy Ward :


At this point I’d also like to re-affirm that the OSGi RFC documents

are

public, and that there is a public feedback mechanism for RFC bugs. As

the

holder of the pen for Transaction Control, the JAX-RS whiteboard, and

the

JPA service updates I can truthfully say that community discussion and
feedback has influenced the direction of those RFCs/specifications, not
just the converter.

As David says below, you can gain increased control over the direction

of

things anywhere by becoming a member/committer/employee. Committers in
Apache Aries have ample opportunity to review and discuss the many
implementations built there, just as they do in Felix. This right

applies

both before and after the release of the specification. What Apache
Committers can’t do is make changes to an OSGi RFC/spec, for that they

need

to lobby an OSGi member.


I have no problems with the above.



This is exactly the same for a committer in Eclipse, on Github, or in a
private company, so it leaves Apache committers just as equal as

everyone

else.


I don't care about how Eclipse or Github project are operated.  We're
talking about Apache projects and there are rules.  One of them is that
committers are considered equal.



The main difference here is that there are a lot of OSGi members who
believe in Apache, and therefore contribute as committers. Are we

really

saying that those committers should be disallowed because they are OSGi
members and therefore have “more power”?


Not disallowed, but yes, they should not do something within the ASF

that

other committers who are not OSGi members can't do.
So to be clear: if any committer want to work on an implementation of an
RFC or spec from the OSGi Alliance, that's fine, whether they are OSGi
members or not.
If an OSGi member want to work on spec design within the ASF bounds, I
think that's not fine.   In particular, if someone propose to develop

some

code to implement an RFC when the API from the developped and later
introduced back into the RFC document, I think that's definitely spec

work,

and should not be done within the RFC.

To be crystal clear, I have a problem with Ray willing to bring code for
implementing rfc-193 in Aries, when the code that he wants to bring
contains lots of things that are not reflected in the RFC document and

the

opposite.  Ray and David explained that the RFC document will be

updated in

the coming weeks to reflect those changes.  This is definitely spec

work,

and that's fine, but I don't think it should happen at Apache.  Again,

it's

a timing problem wrt to changes in the document and changes in the code

:

if the code is changes first by the spec lead, and later validated on
during OSGi meetings and later integrated into the spec document and

made

public, I definitely see that as spec work, not as building an
implementation, and imho this is unfair to other committers because it

does

not follow the ASF rules.  It's certainly open source, but not the

Apache

way.


And btw, even from a legal ASF pov, I'm not sure how things hold.  People
are writing code copyrighted to the OSGi Alliance directly in the ASF…


And when *you* write code in the ASF, you own the copyright to that code.
Apache does not require or expect that copyright ownership of the code is
transferred to the ASF, only that it is licensed under the terms of the
ASL. The fact that OSGi Alliance may be the copyright holder of some code
does not present any problems.

Though maybe you shouldn’t seek legal advice on a developer mailing list
;-)


Well, the code does not seem to comply to the ASF rules at leat:
   https://www.apache.org/legal/src-headers.html


1. This section refers only to works submitted directly to the ASF by
the copyright owner or owner's agent.
2. This section refers only to works submitted directly to the ASF by
the copyright owner or owner's agent.
3. If the source file is submitted with a copyright notice included in
it, the copyright owner (or owner's agent) must either:
   1. remove such notices, or
   2. move them to the NOTICE file associated with each applicable
   project release, or
   3. provide written permission for the ASF to make such removal or
   relocation of the notices.
4. Each source file should include the following license header -- note
that there should be no copyright notice in the header:



Committers do sign an ICLA or CCLA.  In both cases, there's a Grant of
Copyright License whereby the owner gives to the ASF "a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable   copyright
license to reproduce, prepare 

Re: Implementation of unreleased spec and community

[Raymond Auge]

Apparently I've severely offended you Guillaume. If so I sincerely
apologize. That was never my intention.

Sincerely,
- Ray

On Jan 20, 2017 5:42 AM, "Guillaume Nodet"  wrote:

2017-01-20 11:26 GMT+01:00 Neil Bartlett :

>
> > On 20 Jan 2017, at 10:12, Guillaume Nodet  wrote:
> >
> > 2017-01-20 10:58 GMT+01:00 Guillaume Nodet >:
> >
> >>
> >>
> >> 2017-01-19 19:36 GMT+01:00 Timothy Ward :
> >>
> >>> At this point I’d also like to re-affirm that the OSGi RFC documents
> are
> >>> public, and that there is a public feedback mechanism for RFC bugs. As
> the
> >>> holder of the pen for Transaction Control, the JAX-RS whiteboard, and
> the
> >>> JPA service updates I can truthfully say that community discussion and
> >>> feedback has influenced the direction of those RFCs/specifications,
not
> >>> just the converter.
> >>>
> >>> As David says below, you can gain increased control over the direction
> of
> >>> things anywhere by becoming a member/committer/employee. Committers in
> >>> Apache Aries have ample opportunity to review and discuss the many
> >>> implementations built there, just as they do in Felix. This right
> applies
> >>> both before and after the release of the specification. What Apache
> >>> Committers can’t do is make changes to an OSGi RFC/spec, for that they
> need
> >>> to lobby an OSGi member.
> >>
> >>
> >> I have no problems with the above.
> >>
> >>
> >>> This is exactly the same for a committer in Eclipse, on Github, or in
a
> >>> private company, so it leaves Apache committers just as equal as
> everyone
> >>> else.
> >>
> >>
> >> I don't care about how Eclipse or Github project are operated.  We're
> >> talking about Apache projects and there are rules.  One of them is that
> >> committers are considered equal.
> >>
> >>
> >>> The main difference here is that there are a lot of OSGi members who
> >>> believe in Apache, and therefore contribute as committers. Are we
> really
> >>> saying that those committers should be disallowed because they are
OSGi
> >>> members and therefore have “more power”?
> >>>
> >>
> >> Not disallowed, but yes, they should not do something within the ASF
> that
> >> other committers who are not OSGi members can't do.
> >> So to be clear: if any committer want to work on an implementation of
an
> >> RFC or spec from the OSGi Alliance, that's fine, whether they are OSGi
> >> members or not.
> >> If an OSGi member want to work on spec design within the ASF bounds, I
> >> think that's not fine.   In particular, if someone propose to develop
> some
> >> code to implement an RFC when the API from the developped and later
> >> introduced back into the RFC document, I think that's definitely spec
> work,
> >> and should not be done within the RFC.
> >>
> >> To be crystal clear, I have a problem with Ray willing to bring code
for
> >> implementing rfc-193 in Aries, when the code that he wants to bring
> >> contains lots of things that are not reflected in the RFC document and
> the
> >> opposite.  Ray and David explained that the RFC document will be
> updated in
> >> the coming weeks to reflect those changes.  This is definitely spec
> work,
> >> and that's fine, but I don't think it should happen at Apache.  Again,
> it's
> >> a timing problem wrt to changes in the document and changes in the code
> :
> >> if the code is changes first by the spec lead, and later validated on
> >> during OSGi meetings and later integrated into the spec document and
> made
> >> public, I definitely see that as spec work, not as building an
> >> implementation, and imho this is unfair to other committers because it
> does
> >> not follow the ASF rules.  It's certainly open source, but not the
> Apache
> >> way.
> >>
> >
> > And btw, even from a legal ASF pov, I'm not sure how things hold.
People
> > are writing code copyrighted to the OSGi Alliance directly in the ASF…
>
>
> And when *you* write code in the ASF, you own the copyright to that code.
> Apache does not require or expect that copyright ownership of the code is
> transferred to the ASF, only that it is licensed under the terms of the
> ASL. The fact that OSGi Alliance may be the copyright holder of some code
> does not present any problems.
>
> Though maybe you shouldn’t seek legal advice on a developer mailing list
> ;-)
>

Well, the code does not seem to comply to the ASF rules at leat:
  https://www.apache.org/legal/src-headers.html


   1. This section refers only to works submitted directly to the ASF by
   the copyright owner or owner's agent.
   2. This section refers only to works submitted directly to the ASF by
   the copyright owner or owner's agent.
   3. If the source file is submitted with a copyright notice included in
   it, the copyright owner (or owner's agent) must either:
  1. remove such notices, or
  2. move them to the NOTICE file associated with each applicable
  

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

2017-01-20 11:26 GMT+01:00 Neil Bartlett :

>
> > On 20 Jan 2017, at 10:12, Guillaume Nodet  wrote:
> >
> > 2017-01-20 10:58 GMT+01:00 Guillaume Nodet >:
> >
> >>
> >>
> >> 2017-01-19 19:36 GMT+01:00 Timothy Ward :
> >>
> >>> At this point I’d also like to re-affirm that the OSGi RFC documents
> are
> >>> public, and that there is a public feedback mechanism for RFC bugs. As
> the
> >>> holder of the pen for Transaction Control, the JAX-RS whiteboard, and
> the
> >>> JPA service updates I can truthfully say that community discussion and
> >>> feedback has influenced the direction of those RFCs/specifications, not
> >>> just the converter.
> >>>
> >>> As David says below, you can gain increased control over the direction
> of
> >>> things anywhere by becoming a member/committer/employee. Committers in
> >>> Apache Aries have ample opportunity to review and discuss the many
> >>> implementations built there, just as they do in Felix. This right
> applies
> >>> both before and after the release of the specification. What Apache
> >>> Committers can’t do is make changes to an OSGi RFC/spec, for that they
> need
> >>> to lobby an OSGi member.
> >>
> >>
> >> I have no problems with the above.
> >>
> >>
> >>> This is exactly the same for a committer in Eclipse, on Github, or in a
> >>> private company, so it leaves Apache committers just as equal as
> everyone
> >>> else.
> >>
> >>
> >> I don't care about how Eclipse or Github project are operated.  We're
> >> talking about Apache projects and there are rules.  One of them is that
> >> committers are considered equal.
> >>
> >>
> >>> The main difference here is that there are a lot of OSGi members who
> >>> believe in Apache, and therefore contribute as committers. Are we
> really
> >>> saying that those committers should be disallowed because they are OSGi
> >>> members and therefore have “more power”?
> >>>
> >>
> >> Not disallowed, but yes, they should not do something within the ASF
> that
> >> other committers who are not OSGi members can't do.
> >> So to be clear: if any committer want to work on an implementation of an
> >> RFC or spec from the OSGi Alliance, that's fine, whether they are OSGi
> >> members or not.
> >> If an OSGi member want to work on spec design within the ASF bounds, I
> >> think that's not fine.   In particular, if someone propose to develop
> some
> >> code to implement an RFC when the API from the developped and later
> >> introduced back into the RFC document, I think that's definitely spec
> work,
> >> and should not be done within the RFC.
> >>
> >> To be crystal clear, I have a problem with Ray willing to bring code for
> >> implementing rfc-193 in Aries, when the code that he wants to bring
> >> contains lots of things that are not reflected in the RFC document and
> the
> >> opposite.  Ray and David explained that the RFC document will be
> updated in
> >> the coming weeks to reflect those changes.  This is definitely spec
> work,
> >> and that's fine, but I don't think it should happen at Apache.  Again,
> it's
> >> a timing problem wrt to changes in the document and changes in the code
> :
> >> if the code is changes first by the spec lead, and later validated on
> >> during OSGi meetings and later integrated into the spec document and
> made
> >> public, I definitely see that as spec work, not as building an
> >> implementation, and imho this is unfair to other committers because it
> does
> >> not follow the ASF rules.  It's certainly open source, but not the
> Apache
> >> way.
> >>
> >
> > And btw, even from a legal ASF pov, I'm not sure how things hold.  People
> > are writing code copyrighted to the OSGi Alliance directly in the ASF…
>
>
> And when *you* write code in the ASF, you own the copyright to that code.
> Apache does not require or expect that copyright ownership of the code is
> transferred to the ASF, only that it is licensed under the terms of the
> ASL. The fact that OSGi Alliance may be the copyright holder of some code
> does not present any problems.
>
> Though maybe you shouldn’t seek legal advice on a developer mailing list
> ;-)
>

Well, the code does not seem to comply to the ASF rules at leat:
  https://www.apache.org/legal/src-headers.html


   1. This section refers only to works submitted directly to the ASF by
   the copyright owner or owner's agent.
   2. This section refers only to works submitted directly to the ASF by
   the copyright owner or owner's agent.
   3. If the source file is submitted with a copyright notice included in
   it, the copyright owner (or owner's agent) must either:
  1. remove such notices, or
  2. move them to the NOTICE file associated with each applicable
  project release, or
  3. provide written permission for the ASF to make such removal or
  relocation of the notices.
   4. Each source file should include the following license header -- 

Re: Implementation of unreleased spec and community

[Neil Bartlett]

> On 20 Jan 2017, at 10:12, Guillaume Nodet  wrote:
> 
> 2017-01-20 10:58 GMT+01:00 Guillaume Nodet  >:
> 
>> 
>> 
>> 2017-01-19 19:36 GMT+01:00 Timothy Ward :
>> 
>>> At this point I’d also like to re-affirm that the OSGi RFC documents are
>>> public, and that there is a public feedback mechanism for RFC bugs. As the
>>> holder of the pen for Transaction Control, the JAX-RS whiteboard, and the
>>> JPA service updates I can truthfully say that community discussion and
>>> feedback has influenced the direction of those RFCs/specifications, not
>>> just the converter.
>>> 
>>> As David says below, you can gain increased control over the direction of
>>> things anywhere by becoming a member/committer/employee. Committers in
>>> Apache Aries have ample opportunity to review and discuss the many
>>> implementations built there, just as they do in Felix. This right applies
>>> both before and after the release of the specification. What Apache
>>> Committers can’t do is make changes to an OSGi RFC/spec, for that they need
>>> to lobby an OSGi member.
>> 
>> 
>> I have no problems with the above.
>> 
>> 
>>> This is exactly the same for a committer in Eclipse, on Github, or in a
>>> private company, so it leaves Apache committers just as equal as everyone
>>> else.
>> 
>> 
>> I don't care about how Eclipse or Github project are operated.  We're
>> talking about Apache projects and there are rules.  One of them is that
>> committers are considered equal.
>> 
>> 
>>> The main difference here is that there are a lot of OSGi members who
>>> believe in Apache, and therefore contribute as committers. Are we really
>>> saying that those committers should be disallowed because they are OSGi
>>> members and therefore have “more power”?
>>> 
>> 
>> Not disallowed, but yes, they should not do something within the ASF that
>> other committers who are not OSGi members can't do.
>> So to be clear: if any committer want to work on an implementation of an
>> RFC or spec from the OSGi Alliance, that's fine, whether they are OSGi
>> members or not.
>> If an OSGi member want to work on spec design within the ASF bounds, I
>> think that's not fine.   In particular, if someone propose to develop some
>> code to implement an RFC when the API from the developped and later
>> introduced back into the RFC document, I think that's definitely spec work,
>> and should not be done within the RFC.
>> 
>> To be crystal clear, I have a problem with Ray willing to bring code for
>> implementing rfc-193 in Aries, when the code that he wants to bring
>> contains lots of things that are not reflected in the RFC document and the
>> opposite.  Ray and David explained that the RFC document will be updated in
>> the coming weeks to reflect those changes.  This is definitely spec work,
>> and that's fine, but I don't think it should happen at Apache.  Again, it's
>> a timing problem wrt to changes in the document and changes in the code :
>> if the code is changes first by the spec lead, and later validated on
>> during OSGi meetings and later integrated into the spec document and made
>> public, I definitely see that as spec work, not as building an
>> implementation, and imho this is unfair to other committers because it does
>> not follow the ASF rules.  It's certainly open source, but not the Apache
>> way.
>> 
> 
> And btw, even from a legal ASF pov, I'm not sure how things hold.  People
> are writing code copyrighted to the OSGi Alliance directly in the ASF…


And when *you* write code in the ASF, you own the copyright to that code. 
Apache does not require or expect that copyright ownership of the code is 
transferred to the ASF, only that it is licensed under the terms of the ASL. 
The fact that OSGi Alliance may be the copyright holder of some code does not 
present any problems.

Though maybe you shouldn’t seek legal advice on a developer mailing list ;-)


> 
> 
>> 
>> 
>>> 
>>> Finally, there are a lot of projects and/or components in Open Source
>>> (including Apache) that are written by a single committer, typically the
>>> person with the itch to scratch. Only If that committer tries to prevent
>>> discussion about, or changes to, that code is there a problem for the
>>> community. To my knowledge this does not apply to any of the components in
>>> Apache Aries or Apache Felix.
>>> 
>> 
>> A piece of code being developed by a single person is definitely not a
>> good thing within the ASF.  Again, the ASF operates with community over
>> code mantra and requires diversity within a project to avoid dictatorship
>> and to ensure that the code development is overseen and can be maintained
>> if one people is going away.  Having some code being developed by a single
>> person certainly does not help. The fact that it has almost always been the
>> case for a bunch of subprojects in Felix or Aries does not mean it's
>> healthy nor good.   But this is 

Re: Implementation of unreleased spec and community

[Christian Schneider]

I agree that if someone works on a spec at OSGi alliance and on the impl 
code at Apache then he will have an advantage over someone

who can only work on the code at Apache. This is a situation is not good.

The question though is what can we really do to improve this. I think it 
is not possible to do spec work without doing the impl at the same time. 
It would be like creating the full design of a system without writing 
code. The design would be bad as the feedback cycle of actual usage 
would be missing.


Forcing reference implementation out of Apache would be a bad choice in 
my opinion. We as the Apache community gain a lot of indirect influence 
on the specs by being able to review and comment the code changes early. 
I think this outweighs the advantage some people have by being spec 
designers and implementers at the same time.


I think the main problem really arises when the spec designer works on 
the code, changes it in a way that is not reflected in the spec and when 
asked about it replies : These changes will be reflected in the spec at 
a later point. The problem with this is that it can end any discussion 
as "the spec is always right".


So I think what we can do is apply certain rules for specs being 
implemented at Aries or Felix. So one thing I can imagine is that 
changes not reflected by the current publicly available spec have to be 
done in a branch until they are reflected in the spec. We could also 
require that the most current version of the spec and accompanying api 
(source and binary) must be available. This rules would make sure that 
the mater always reflects the current spec and that at least on master 
people working on the impl are equal.


Of course the big question is if such rules would work in practice or if 
they would just make working in the Apache project more difficult for 
the spec designers. I would hate if in the end the specs would just be 
implemented somewhere else without our community.


Christian


On 20.01.2017 10:58, Guillaume Nodet wrote:

The main difference here is that there are a lot of OSGi members who
believe in Apache, and therefore contribute as committers. Are we really
saying that those committers should be disallowed because they are OSGi
members and therefore have “more power”?


Not disallowed, but yes, they should not do something within the ASF that
other committers who are not OSGi members can't do.
So to be clear: if any committer want to work on an implementation of an
RFC or spec from the OSGi Alliance, that's fine, whether they are OSGi
members or not.
If an OSGi member want to work on spec design within the ASF bounds, I
think that's not fine.   In particular, if someone propose to develop some
code to implement an RFC when the API from the developped and later
introduced back into the RFC document, I think that's definitely spec work,
and should not be done within the RFC.

To be crystal clear, I have a problem with Ray willing to bring code for
implementing rfc-193 in Aries, when the code that he wants to bring
contains lots of things that are not reflected in the RFC document and the
opposite.  Ray and David explained that the RFC document will be updated in
the coming weeks to reflect those changes.  This is definitely spec work,
and that's fine, but I don't think it should happen at Apache.  Again, it's
a timing problem wrt to changes in the document and changes in the code :
if the code is changes first by the spec lead, and later validated on
during OSGi meetings and later integrated into the spec document and made
public, I definitely see that as spec work, not as building an
implementation, and imho this is unfair to other committers because it does
not follow the ASF rules.  It's certainly open source, but not the Apache
way.




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

2017-01-20 10:58 GMT+01:00 Guillaume Nodet :

>
>
> 2017-01-19 19:36 GMT+01:00 Timothy Ward :
>
>> At this point I’d also like to re-affirm that the OSGi RFC documents are
>> public, and that there is a public feedback mechanism for RFC bugs. As the
>> holder of the pen for Transaction Control, the JAX-RS whiteboard, and the
>> JPA service updates I can truthfully say that community discussion and
>> feedback has influenced the direction of those RFCs/specifications, not
>> just the converter.
>>
>> As David says below, you can gain increased control over the direction of
>> things anywhere by becoming a member/committer/employee. Committers in
>> Apache Aries have ample opportunity to review and discuss the many
>> implementations built there, just as they do in Felix. This right applies
>> both before and after the release of the specification. What Apache
>> Committers can’t do is make changes to an OSGi RFC/spec, for that they need
>> to lobby an OSGi member.
>
>
> I have no problems with the above.
>
>
>> This is exactly the same for a committer in Eclipse, on Github, or in a
>> private company, so it leaves Apache committers just as equal as everyone
>> else.
>
>
> I don't care about how Eclipse or Github project are operated.  We're
> talking about Apache projects and there are rules.  One of them is that
> committers are considered equal.
>
>
>> The main difference here is that there are a lot of OSGi members who
>> believe in Apache, and therefore contribute as committers. Are we really
>> saying that those committers should be disallowed because they are OSGi
>> members and therefore have “more power”?
>>
>
> Not disallowed, but yes, they should not do something within the ASF that
> other committers who are not OSGi members can't do.
> So to be clear: if any committer want to work on an implementation of an
> RFC or spec from the OSGi Alliance, that's fine, whether they are OSGi
> members or not.
> If an OSGi member want to work on spec design within the ASF bounds, I
> think that's not fine.   In particular, if someone propose to develop some
> code to implement an RFC when the API from the developped and later
> introduced back into the RFC document, I think that's definitely spec work,
> and should not be done within the RFC.
>
> To be crystal clear, I have a problem with Ray willing to bring code for
> implementing rfc-193 in Aries, when the code that he wants to bring
> contains lots of things that are not reflected in the RFC document and the
> opposite.  Ray and David explained that the RFC document will be updated in
> the coming weeks to reflect those changes.  This is definitely spec work,
> and that's fine, but I don't think it should happen at Apache.  Again, it's
> a timing problem wrt to changes in the document and changes in the code :
> if the code is changes first by the spec lead, and later validated on
> during OSGi meetings and later integrated into the spec document and made
> public, I definitely see that as spec work, not as building an
> implementation, and imho this is unfair to other committers because it does
> not follow the ASF rules.  It's certainly open source, but not the Apache
> way.
>

And btw, even from a legal ASF pov, I'm not sure how things hold.  People
are writing code copyrighted to the OSGi Alliance directly in the ASF...


>
>
>>
>> Finally, there are a lot of projects and/or components in Open Source
>> (including Apache) that are written by a single committer, typically the
>> person with the itch to scratch. Only If that committer tries to prevent
>> discussion about, or changes to, that code is there a problem for the
>> community. To my knowledge this does not apply to any of the components in
>> Apache Aries or Apache Felix.
>>
>
> A piece of code being developed by a single person is definitely not a
> good thing within the ASF.  Again, the ASF operates with community over
> code mantra and requires diversity within a project to avoid dictatorship
> and to ensure that the code development is overseen and can be maintained
> if one people is going away.  Having some code being developed by a single
> person certainly does not help. The fact that it has almost always been the
> case for a bunch of subprojects in Felix or Aries does not mean it's
> healthy nor good.   But this is slightly mitigated by the fact that over
> time, people tend to jump and fix things when they need.
>
> Obviously, if that person would try to prevent discussion or code changes,
> that would be definitely a critical problem, but I haven't seen such a
> behavior.
>
>
>>
>> Best Regards,
>>
>> Tim Ward
>>
>> > On 19 Jan 2017, at 17:32, David Leangen  wrote:
>> >
>> >>> Ray has listed a number of things that have been implemented during
>> the
>> >>> past few months.  All of them have been written by a single committer
>> who
>> >>> also happen to be the one modifying the spec document.
>> >>>
>> >>>
>> >> This 

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

2017-01-19 19:36 GMT+01:00 Timothy Ward :

> At this point I’d also like to re-affirm that the OSGi RFC documents are
> public, and that there is a public feedback mechanism for RFC bugs. As the
> holder of the pen for Transaction Control, the JAX-RS whiteboard, and the
> JPA service updates I can truthfully say that community discussion and
> feedback has influenced the direction of those RFCs/specifications, not
> just the converter.
>
> As David says below, you can gain increased control over the direction of
> things anywhere by becoming a member/committer/employee. Committers in
> Apache Aries have ample opportunity to review and discuss the many
> implementations built there, just as they do in Felix. This right applies
> both before and after the release of the specification. What Apache
> Committers can’t do is make changes to an OSGi RFC/spec, for that they need
> to lobby an OSGi member.


I have no problems with the above.


> This is exactly the same for a committer in Eclipse, on Github, or in a
> private company, so it leaves Apache committers just as equal as everyone
> else.


I don't care about how Eclipse or Github project are operated.  We're
talking about Apache projects and there are rules.  One of them is that
committers are considered equal.


> The main difference here is that there are a lot of OSGi members who
> believe in Apache, and therefore contribute as committers. Are we really
> saying that those committers should be disallowed because they are OSGi
> members and therefore have “more power”?
>

Not disallowed, but yes, they should not do something within the ASF that
other committers who are not OSGi members can't do.
So to be clear: if any committer want to work on an implementation of an
RFC or spec from the OSGi Alliance, that's fine, whether they are OSGi
members or not.
If an OSGi member want to work on spec design within the ASF bounds, I
think that's not fine.   In particular, if someone propose to develop some
code to implement an RFC when the API from the developped and later
introduced back into the RFC document, I think that's definitely spec work,
and should not be done within the RFC.

To be crystal clear, I have a problem with Ray willing to bring code for
implementing rfc-193 in Aries, when the code that he wants to bring
contains lots of things that are not reflected in the RFC document and the
opposite.  Ray and David explained that the RFC document will be updated in
the coming weeks to reflect those changes.  This is definitely spec work,
and that's fine, but I don't think it should happen at Apache.  Again, it's
a timing problem wrt to changes in the document and changes in the code :
if the code is changes first by the spec lead, and later validated on
during OSGi meetings and later integrated into the spec document and made
public, I definitely see that as spec work, not as building an
implementation, and imho this is unfair to other committers because it does
not follow the ASF rules.  It's certainly open source, but not the Apache
way.


>
> Finally, there are a lot of projects and/or components in Open Source
> (including Apache) that are written by a single committer, typically the
> person with the itch to scratch. Only If that committer tries to prevent
> discussion about, or changes to, that code is there a problem for the
> community. To my knowledge this does not apply to any of the components in
> Apache Aries or Apache Felix.
>

A piece of code being developed by a single person is definitely not a good
thing within the ASF.  Again, the ASF operates with community over code
mantra and requires diversity within a project to avoid dictatorship and to
ensure that the code development is overseen and can be maintained if one
people is going away.  Having some code being developed by a single person
certainly does not help. The fact that it has almost always been the case
for a bunch of subprojects in Felix or Aries does not mean it's healthy nor
good.   But this is slightly mitigated by the fact that over time, people
tend to jump and fix things when they need.

Obviously, if that person would try to prevent discussion or code changes,
that would be definitely a critical problem, but I haven't seen such a
behavior.


>
> Best Regards,
>
> Tim Ward
>
> > On 19 Jan 2017, at 17:32, David Leangen  wrote:
> >
> >>> Ray has listed a number of things that have been implemented during the
> >>> past few months.  All of them have been written by a single committer
> who
> >>> also happen to be the one modifying the spec document.
> >>>
> >>>
> >> This is factually incorrect at least for the Converter implementation at
> >> Felix. Just look at the commit history for commits done on behalf of
> >> community members and also check the mailing list for discussions that
> >> definitely provided great feedback on the work done.
> >
> > I have been doing a very tiny bit of work on the Converter as a double
> outsider 

Re: Implementation of unreleased spec and community

[Carsten Ziegeler]

Thanks Guillaume for bringing this up and thanks everyone for the
orderly discussions. I think it's important that someone brings up his
concerns, that we value this and we can discuss about it.

Looking at the various responses in this thread I have the feeling that
all arguments are on the table. While it seems that most of us do not
see a problem with the current situation, I would like to know if anyone
has a concrete proposal on how to improve or change things? Please keep
in mind that we can only change the Apache side. If you want to change
how the OSGi Alliance works, please take it up with the Alliance.

So if you have any idea or proposal please bring it on.

Thanks

Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Implementation of unreleased spec and community

[Timothy Ward]

At this point I’d also like to re-affirm that the OSGi RFC documents are 
public, and that there is a public feedback mechanism for RFC bugs. As the 
holder of the pen for Transaction Control, the JAX-RS whiteboard, and the JPA 
service updates I can truthfully say that community discussion and feedback has 
influenced the direction of those RFCs/specifications, not just the converter.

As David says below, you can gain increased control over the direction of 
things anywhere by becoming a member/committer/employee. Committers in Apache 
Aries have ample opportunity to review and discuss the many implementations 
built there, just as they do in Felix. This right applies both before and after 
the release of the specification. What Apache Committers can’t do is make 
changes to an OSGi RFC/spec, for that they need to lobby an OSGi member. This 
is exactly the same for a committer in Eclipse, on Github, or in a private 
company, so it leaves Apache committers just as equal as everyone else. The 
main difference here is that there are a lot of OSGi members who believe in 
Apache, and therefore contribute as committers. Are we really saying that those 
committers should be disallowed because they are OSGi members and therefore 
have “more power”?

Finally, there are a lot of projects and/or components in Open Source 
(including Apache) that are written by a single committer, typically the person 
with the itch to scratch. Only If that committer tries to prevent discussion 
about, or changes to, that code is there a problem for the community. To my 
knowledge this does not apply to any of the components in Apache Aries or 
Apache Felix.

Best Regards,

Tim Ward

> On 19 Jan 2017, at 17:32, David Leangen  wrote:
> 
>>> Ray has listed a number of things that have been implemented during the
>>> past few months.  All of them have been written by a single committer who
>>> also happen to be the one modifying the spec document.
>>> 
>>> 
>> This is factually incorrect at least for the Converter implementation at
>> Felix. Just look at the commit history for commits done on behalf of
>> community members and also check the mailing list for discussions that
>> definitely provided great feedback on the work done.
> 
> I have been doing a very tiny bit of work on the Converter as a double 
> outsider (non committer in Felix, and non OSGi member).
> 
> I completely rely on others to accept my contributions and suggestions, 
> making me a kind of second class citizen. It does work, but I need to either 
> (i) become a first class citizen either by merit or paying fees, depending on 
> the organisation, or (ii) accept my dependence on the goodwill of others. 
> Currently I have a de facto sponsor who has been very attentive to my 
> questions and contributions, so (ii) is working out well enough. If it didn’t 
> work out, could always fall back on option (i).
> 
> So I can understand the frustrations and agree that there is a bit of a grey 
> area, but at the same time I understand that in the end I have the same 
> opportunities as everybody else. In this case, I am not willing/able to “pay 
> the price” for full citizenship, so I don’t feel I have the right to complain.
> 
> 
> Just my 2¥.
> 
> Cheers,
> =David
> 
> 

Re: Implementation of unreleased spec and community

[David Leangen]

>> Ray has listed a number of things that have been implemented during the
>> past few months.  All of them have been written by a single committer who
>> also happen to be the one modifying the spec document.
>> 
>> 
> This is factually incorrect at least for the Converter implementation at
> Felix. Just look at the commit history for commits done on behalf of
> community members and also check the mailing list for discussions that
> definitely provided great feedback on the work done.

I have been doing a very tiny bit of work on the Converter as a double outsider 
(non committer in Felix, and non OSGi member).

I completely rely on others to accept my contributions and suggestions, making 
me a kind of second class citizen. It does work, but I need to either (i) 
become a first class citizen either by merit or paying fees, depending on the 
organisation, or (ii) accept my dependence on the goodwill of others. Currently 
I have a de facto sponsor who has been very attentive to my questions and 
contributions, so (ii) is working out well enough. If it didn’t work out, could 
always fall back on option (i).

So I can understand the frustrations and agree that there is a bit of a grey 
area, but at the same time I understand that in the end I have the same 
opportunities as everybody else. In this case, I am not willing/able to “pay 
the price” for full citizenship, so I don’t feel I have the right to complain.


Just my 2¥.

Cheers,
=David

Re: Implementation of unreleased spec and community

[David Bosschaert]

Hi Guillaume

On 18 January 2017 at 23:03, Guillaume Nodet  wrote:

> Ray has listed a number of things that have been implemented during the
> past few months.  All of them have been written by a single committer who
> also happen to be the one modifying the spec document.
>
>
This is factually incorrect at least for the Converter implementation at
Felix. Just look at the commit history for commits done on behalf of
community members and also check the mailing list for discussions that
definitely provided great feedback on the work done.

David

Re: Implementation of unreleased spec and community

[Richard S. Hall]

On 1/18/17 18:03 , Guillaume Nodet wrote:

The problem is when the "what" is being prototyped in an Apache project,
not the "how".  The "how" can be done by any committer, but if the "what"
is still being discussed, you really have no saying over the "how" yet.
Basically, no one will ever question an implementation decision until the
spec work is finished.  Which means that no one will question anything
until the implementation (if that's the RI) is finished too, at which
point, there's nothing to say anymore, unless you want to rewrite the whole
thing.
That's definitely not community work.

So you're right, it's temporary until the spec work is published, at which
point the implementation is also finished and it's too late.  Especially if
the RI will have to be released roughly at the same time than the spec.

Ray has listed a number of things that have been implemented during the
past few months.  All of them have been written by a single committer who
also happen to be the one modifying the spec document.  So I don't see any
real ground for invoking a community involvement, when there's definitely
none.  If what you think about community work is limited to reading
existing code and eventually providing a few comments, those things can
easily be done anywhere.


I disagree that it is not possible to have say over the "how" if you 
don't have any say over the "what" while it is being developed, unless 
there is an active effort by the people involved to not answer questions 
and/or hide what they are doing.


Is it more work when you don't have a complete spec? Sure, because it 
involves actually engaging others to get answers or combing through code 
to figure it out (like you have to do in most open source projects).


I'm not sure this discussion is bearing any fruit. Is there something 
you'd like to propose? If I were to agree that this is an issue, then 
the only thing I can see to resolve it is banning all work on 
provisional specs, which definitely doesn't seem like a good course of 
action.


-> richard






Guillaume

2017-01-18 21:52 GMT+01:00 Richard S. Hall :


On 1/18/17 15:28 , Guillaume Nodet wrote:


2017-01-18 20:23 GMT+01:00 Richard S. Hall :

On 1/18/17 14:06 , Guillaume Nodet wrote:

Let's take a clearer example, as I have a feeling I'm still not

understood
correctly.  My problem is definitely not the fact that there is an
implementation based on an unreleased spec or RFC (as my email title
seemed
to indicate).

If a committer comes and say : I'd like to implement rfc-xxx based on
the
public document (spec or rfc), that's very fine with me, because all
committers have the same level of information and can get involved.
   Fwiw,
that's what usually happens and I haven't seen anything different in
Felix
so far.

If someone comes and say: I'd like to work on some code which will
eventually become the RI while writing the rfc within the OSGi
alliance, I
don't think that's fine, because what we have in this case is not an
implementation of something, it's a prototype for designing the spec and
only OSGi Alliance members who are actually working on the rfc can
really
change the api.

Is that more clear now ?  Am I the only one thinking that if not all
committers can work on the code, there's a real problem ?

This is what I assumed that you meant and I don't really see an issue

with
it. Yeah, it might be more painful than if there was a public document
somewhere, but this is a little bit of a chicken-and-egg situation that
will eventually clear itself up.

http://community.apache.org/committers/decisionMaking.html


The first phrase is the following:
 The most important thing about engaging with any Apache project is
that
everyone is equal.


They are equal in the eyes of Apache, but that doesn't mean that they are
equal with respects to their external memberships. You appear to want to go
down a rat hole that has no escape. No matter what, committers who are
members of standards bodies are "not equal" to committers who are not in
the eyes of the standards bodies. This is true with regardless of whether
the spec is released or not, so I'm still not sure of your point.

People in the standards body have more say in how things will go in what
will ultimately be implemented, but they do not have any more say in how it
will be implemented in any given Apache project. They just get a leg up on
implementing it before the spec is completely public, but that doesn't make
their kung-fu more equal than anyone else and they will still be
accountable for any technical discussions/decisions/debates that ensue as a
result.



Of course, if you had someone purposely trying to keep people in the dark,

then this might be an issue, but I don't think this is a real concern and
certainly not something we've ever experienced. I have to assume that
someone doing the implementation work here would want to discuss with
other
people and get input, otherwise why 

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

The problem is when the "what" is being prototyped in an Apache project,
not the "how".  The "how" can be done by any committer, but if the "what"
is still being discussed, you really have no saying over the "how" yet.
Basically, no one will ever question an implementation decision until the
spec work is finished.  Which means that no one will question anything
until the implementation (if that's the RI) is finished too, at which
point, there's nothing to say anymore, unless you want to rewrite the whole
thing.
That's definitely not community work.

So you're right, it's temporary until the spec work is published, at which
point the implementation is also finished and it's too late.  Especially if
the RI will have to be released roughly at the same time than the spec.

Ray has listed a number of things that have been implemented during the
past few months.  All of them have been written by a single committer who
also happen to be the one modifying the spec document.  So I don't see any
real ground for invoking a community involvement, when there's definitely
none.  If what you think about community work is limited to reading
existing code and eventually providing a few comments, those things can
easily be done anywhere.

Guillaume

2017-01-18 21:52 GMT+01:00 Richard S. Hall :

> On 1/18/17 15:28 , Guillaume Nodet wrote:
>
>> 2017-01-18 20:23 GMT+01:00 Richard S. Hall :
>>
>> On 1/18/17 14:06 , Guillaume Nodet wrote:
>>>
>>> Let's take a clearer example, as I have a feeling I'm still not
 understood
 correctly.  My problem is definitely not the fact that there is an
 implementation based on an unreleased spec or RFC (as my email title
 seemed
 to indicate).

 If a committer comes and say : I'd like to implement rfc-xxx based on
 the
 public document (spec or rfc), that's very fine with me, because all
 committers have the same level of information and can get involved.
   Fwiw,
 that's what usually happens and I haven't seen anything different in
 Felix
 so far.

 If someone comes and say: I'd like to work on some code which will
 eventually become the RI while writing the rfc within the OSGi
 alliance, I
 don't think that's fine, because what we have in this case is not an
 implementation of something, it's a prototype for designing the spec and
 only OSGi Alliance members who are actually working on the rfc can
 really
 change the api.

 Is that more clear now ?  Am I the only one thinking that if not all
 committers can work on the code, there's a real problem ?

 This is what I assumed that you meant and I don't really see an issue
>>> with
>>> it. Yeah, it might be more painful than if there was a public document
>>> somewhere, but this is a little bit of a chicken-and-egg situation that
>>> will eventually clear itself up.
>>>
>>> http://community.apache.org/committers/decisionMaking.html
>>>
>> The first phrase is the following:
>> The most important thing about engaging with any Apache project is
>> that
>> everyone is equal.
>>
>
> They are equal in the eyes of Apache, but that doesn't mean that they are
> equal with respects to their external memberships. You appear to want to go
> down a rat hole that has no escape. No matter what, committers who are
> members of standards bodies are "not equal" to committers who are not in
> the eyes of the standards bodies. This is true with regardless of whether
> the spec is released or not, so I'm still not sure of your point.
>
> People in the standards body have more say in how things will go in what
> will ultimately be implemented, but they do not have any more say in how it
> will be implemented in any given Apache project. They just get a leg up on
> implementing it before the spec is completely public, but that doesn't make
> their kung-fu more equal than anyone else and they will still be
> accountable for any technical discussions/decisions/debates that ensue as a
> result.
>
>
>>
>> Of course, if you had someone purposely trying to keep people in the dark,
>>> then this might be an issue, but I don't think this is a real concern and
>>> certainly not something we've ever experienced. I have to assume that
>>> someone doing the implementation work here would want to discuss with
>>> other
>>> people and get input, otherwise why would they be doing the work here in
>>> the first place?
>>>
>>
>> Well, I have to assume that someone doing the implementation work here
>> would want to obey the Apache rules, otherwise why would they be doing the
>> work here in the first place?
>>
>
> But you seem to be implying that they aren't obeying the rules because
> they have access to unreleased specs which doesn't really hold water with
> me.
>
> The only thing that you are saying that is true is that people will have
> some difficulty contributing if they don't have the spec to read. Sure,
> this is 

Re: Implementation of unreleased spec and community

[Richard S. Hall]

On 1/18/17 15:28 , Guillaume Nodet wrote:

2017-01-18 20:23 GMT+01:00 Richard S. Hall :


On 1/18/17 14:06 , Guillaume Nodet wrote:


Let's take a clearer example, as I have a feeling I'm still not understood
correctly.  My problem is definitely not the fact that there is an
implementation based on an unreleased spec or RFC (as my email title
seemed
to indicate).

If a committer comes and say : I'd like to implement rfc-xxx based on the
public document (spec or rfc), that's very fine with me, because all
committers have the same level of information and can get involved.
  Fwiw,
that's what usually happens and I haven't seen anything different in Felix
so far.

If someone comes and say: I'd like to work on some code which will
eventually become the RI while writing the rfc within the OSGi alliance, I
don't think that's fine, because what we have in this case is not an
implementation of something, it's a prototype for designing the spec and
only OSGi Alliance members who are actually working on the rfc can really
change the api.

Is that more clear now ?  Am I the only one thinking that if not all
committers can work on the code, there's a real problem ?


This is what I assumed that you meant and I don't really see an issue with
it. Yeah, it might be more painful than if there was a public document
somewhere, but this is a little bit of a chicken-and-egg situation that
will eventually clear itself up.

http://community.apache.org/committers/decisionMaking.html

The first phrase is the following:
The most important thing about engaging with any Apache project is that
everyone is equal.


They are equal in the eyes of Apache, but that doesn't mean that they 
are equal with respects to their external memberships. You appear to 
want to go down a rat hole that has no escape. No matter what, 
committers who are members of standards bodies are "not equal" to 
committers who are not in the eyes of the standards bodies. This is true 
with regardless of whether the spec is released or not, so I'm still not 
sure of your point.


People in the standards body have more say in how things will go in what 
will ultimately be implemented, but they do not have any more say in how 
it will be implemented in any given Apache project. They just get a leg 
up on implementing it before the spec is completely public, but that 
doesn't make their kung-fu more equal than anyone else and they will 
still be accountable for any technical discussions/decisions/debates 
that ensue as a result.






Of course, if you had someone purposely trying to keep people in the dark,
then this might be an issue, but I don't think this is a real concern and
certainly not something we've ever experienced. I have to assume that
someone doing the implementation work here would want to discuss with other
people and get input, otherwise why would they be doing the work here in
the first place?


Well, I have to assume that someone doing the implementation work here
would want to obey the Apache rules, otherwise why would they be doing the
work here in the first place?


But you seem to be implying that they aren't obeying the rules because 
they have access to unreleased specs which doesn't really hold water 
with me.


The only thing that you are saying that is true is that people will have 
some difficulty contributing if they don't have the spec to read. Sure, 
this is probably the case, but this certainly doesn't prevent people 
from commenting and/or contributing to it. Most open source work doesn't 
have a spec for people to work against and they still generally jump in 
and contribute. And, as I said before, it is only temporary.


-> richard






-> richard





2017-01-18 15:29 GMT+01:00 Neil Bartlett :

On 18 Jan 2017, at 12:36, Guillaume Nodet  wrote:

Fwiw, I think Christian was referring to the JAX-RS WHITEBOARD, not the
JAX-RS spec itself.
That one is an RFC from the OSGi Alliance...  RFC-127 afaik.


This is pretty much my point. Why raise an issue with the “Whiteboard”
half of “JAX-RS Whiteboard” but not with the “JAX-RS” half? Why don’t
your
arguments also apply to JCR specs, or IEEE or W3C specs?

Regards,
Neil

2017-01-18 13:34 GMT+01:00 Neil Bartlett :

Christian, your example of JAX-RS Whiteboard is fascinating, because

JAX-RS was designed by the Expert Groups of the JCP, not by the Apache
community. The same is true of many of the JavaEE specifications
implemented within Apache.

So, Apache has always worked pragmatically to implement specifications
emerging from external standards bodies. It seems odd therefore to


single
out OSGi.

Neil

On 18 Jan 2017, at 11:25, Christian Schneider 

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

2017-01-18 20:23 GMT+01:00 Richard S. Hall :

> On 1/18/17 14:06 , Guillaume Nodet wrote:
>
>> Let's take a clearer example, as I have a feeling I'm still not understood
>> correctly.  My problem is definitely not the fact that there is an
>> implementation based on an unreleased spec or RFC (as my email title
>> seemed
>> to indicate).
>>
>> If a committer comes and say : I'd like to implement rfc-xxx based on the
>> public document (spec or rfc), that's very fine with me, because all
>> committers have the same level of information and can get involved.
>>  Fwiw,
>> that's what usually happens and I haven't seen anything different in Felix
>> so far.
>>
>> If someone comes and say: I'd like to work on some code which will
>> eventually become the RI while writing the rfc within the OSGi alliance, I
>> don't think that's fine, because what we have in this case is not an
>> implementation of something, it's a prototype for designing the spec and
>> only OSGi Alliance members who are actually working on the rfc can really
>> change the api.
>>
>> Is that more clear now ?  Am I the only one thinking that if not all
>> committers can work on the code, there's a real problem ?
>>
>
> This is what I assumed that you meant and I don't really see an issue with
> it. Yeah, it might be more painful than if there was a public document
> somewhere, but this is a little bit of a chicken-and-egg situation that
> will eventually clear itself up.
>
> http://community.apache.org/committers/decisionMaking.html
The first phrase is the following:
   The most important thing about engaging with any Apache project is that
everyone is equal.


> Of course, if you had someone purposely trying to keep people in the dark,
> then this might be an issue, but I don't think this is a real concern and
> certainly not something we've ever experienced. I have to assume that
> someone doing the implementation work here would want to discuss with other
> people and get input, otherwise why would they be doing the work here in
> the first place?


Well, I have to assume that someone doing the implementation work here
would want to obey the Apache rules, otherwise why would they be doing the
work here in the first place?


>
>
> -> richard
>
>
>
>>
>>
>> 2017-01-18 15:29 GMT+01:00 Neil Bartlett :
>>
>> On 18 Jan 2017, at 12:36, Guillaume Nodet  wrote:

 Fwiw, I think Christian was referring to the JAX-RS WHITEBOARD, not the
 JAX-RS spec itself.
 That one is an RFC from the OSGi Alliance...  RFC-127 afaik.

>>> This is pretty much my point. Why raise an issue with the “Whiteboard”
>>> half of “JAX-RS Whiteboard” but not with the “JAX-RS” half? Why don’t
>>> your
>>> arguments also apply to JCR specs, or IEEE or W3C specs?
>>>
>>> Regards,
>>> Neil
>>>
>>> 2017-01-18 13:34 GMT+01:00 Neil Bartlett :

 Christian, your example of JAX-RS Whiteboard is fascinating, because
> JAX-RS was designed by the Expert Groups of the JCP, not by the Apache
> community. The same is true of many of the JavaEE specifications
> implemented within Apache.
>
> So, Apache has always worked pragmatically to implement specifications
> emerging from external standards bodies. It seems odd therefore to
>
 single
>>>
 out OSGi.
>
> Neil
>
> On 18 Jan 2017, at 11:25, Christian Schneider >
> wrote:
>
>> I agree with Guillaume that the way the specs are defined is not fully
>>
> compatible to the way apache projects are managed.
>
>> In apache the idea is that the design of a component is defined by the
>>
> community.
>
>> Like in jax-rs-whiteboard .. if it was a pure apache thing then
>> changes
>>
> in the interfaces would be proposed on the dev list and agreed on
> there.
>
>> As the interfaces are part of the spec this is out of direct reach for
>>
> the aries community.
>
>> On the other hand I understand that the final decision about the spec
>>
> has to be at the OSGi alliance and even that only members may decide.
>
>> So I think this gap can not be fully solved but maybe we can improve
>>
> it.
>>>
 So what I could imagine is this:
>>
>> - Changes on the spec should be immediately visible to the apache
>>
> community. This could be done using a github repo where the source of
>
 the
>>>
 spec resides and an automated snapshot build. So all changes could be
> followed directly and the newest spec jars  would always be available.
>
>> - Protocols of the expert group meetings could be posted to the dev
>>
> list
>>>
 Both improvements would shorten the feedback loop and give the apache
>>
> community at least more visibility of the spec progress. The community
> could then also directly give feedback to 

Re: Implementation of unreleased spec and community

[Carsten Ziegeler]

Richard S. Hall wrote
> On 1/18/17 14:06 , Guillaume Nodet wrote:
>> Let's take a clearer example, as I have a feeling I'm still not
>> understood
>> correctly.  My problem is definitely not the fact that there is an
>> implementation based on an unreleased spec or RFC (as my email title
>> seemed
>> to indicate).
>>
>> If a committer comes and say : I'd like to implement rfc-xxx based on the
>> public document (spec or rfc), that's very fine with me, because all
>> committers have the same level of information and can get involved.  
>> Fwiw,
>> that's what usually happens and I haven't seen anything different in
>> Felix
>> so far.
>>
>> If someone comes and say: I'd like to work on some code which will
>> eventually become the RI while writing the rfc within the OSGi
>> alliance, I
>> don't think that's fine, because what we have in this case is not an
>> implementation of something, it's a prototype for designing the spec and
>> only OSGi Alliance members who are actually working on the rfc can really
>> change the api.
>>
>> Is that more clear now ?  Am I the only one thinking that if not all
>> committers can work on the code, there's a real problem ?
> 
> This is what I assumed that you meant and I don't really see an issue
> with it. Yeah, it might be more painful than if there was a public
> document somewhere, but this is a little bit of a chicken-and-egg
> situation that will eventually clear itself up.
> 
> Of course, if you had someone purposely trying to keep people in the
> dark, then this might be an issue, but I don't think this is a real
> concern and certainly not something we've ever experienced. I have to
> assume that someone doing the implementation work here would want to
> discuss with other people and get input, otherwise why would they be
> doing the work here in the first place?
> 

Exactly, for example two people asked me to put the implementation for
the Configurator in Felix so they can have a look and comment/help.

Or take the Converter as an even better example. There is feedback from
the community here which has already influenced the spec.

So there is a clear benefit of doing it this way.

And all committers can work on the code, everyone is invited to help
with the implementation and shape the design of the implementation. The
API is of course defined by the OSGi alliance. However, feedback through
the mentioned channels is of course possible.

Regards
Carsten

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Implementation of unreleased spec and community

[Richard S. Hall]

On 1/18/17 14:06 , Guillaume Nodet wrote:

Let's take a clearer example, as I have a feeling I'm still not understood
correctly.  My problem is definitely not the fact that there is an
implementation based on an unreleased spec or RFC (as my email title seemed
to indicate).

If a committer comes and say : I'd like to implement rfc-xxx based on the
public document (spec or rfc), that's very fine with me, because all
committers have the same level of information and can get involved.   Fwiw,
that's what usually happens and I haven't seen anything different in Felix
so far.

If someone comes and say: I'd like to work on some code which will
eventually become the RI while writing the rfc within the OSGi alliance, I
don't think that's fine, because what we have in this case is not an
implementation of something, it's a prototype for designing the spec and
only OSGi Alliance members who are actually working on the rfc can really
change the api.

Is that more clear now ?  Am I the only one thinking that if not all
committers can work on the code, there's a real problem ?


This is what I assumed that you meant and I don't really see an issue 
with it. Yeah, it might be more painful than if there was a public 
document somewhere, but this is a little bit of a chicken-and-egg 
situation that will eventually clear itself up.


Of course, if you had someone purposely trying to keep people in the 
dark, then this might be an issue, but I don't think this is a real 
concern and certainly not something we've ever experienced. I have to 
assume that someone doing the implementation work here would want to 
discuss with other people and get input, otherwise why would they be 
doing the work here in the first place?


-> richard





2017-01-18 15:29 GMT+01:00 Neil Bartlett :


On 18 Jan 2017, at 12:36, Guillaume Nodet  wrote:

Fwiw, I think Christian was referring to the JAX-RS WHITEBOARD, not the
JAX-RS spec itself.
That one is an RFC from the OSGi Alliance...  RFC-127 afaik.

This is pretty much my point. Why raise an issue with the “Whiteboard”
half of “JAX-RS Whiteboard” but not with the “JAX-RS” half? Why don’t your
arguments also apply to JCR specs, or IEEE or W3C specs?

Regards,
Neil


2017-01-18 13:34 GMT+01:00 Neil Bartlett :


Christian, your example of JAX-RS Whiteboard is fascinating, because
JAX-RS was designed by the Expert Groups of the JCP, not by the Apache
community. The same is true of many of the JavaEE specifications
implemented within Apache.

So, Apache has always worked pragmatically to implement specifications
emerging from external standards bodies. It seems odd therefore to

single

out OSGi.

Neil


On 18 Jan 2017, at 11:25, Christian Schneider 

Re: Implementation of unreleased spec and community

[Raymond Auge]

But this is exactly what is happening for many in-flight specifications and
no one has ever complained!

- tx-control
- push streams
- configurator
- converter
- etc.

- Ray

On Wed, Jan 18, 2017 at 2:06 PM, Guillaume Nodet  wrote:

> Let's take a clearer example, as I have a feeling I'm still not understood
> correctly.  My problem is definitely not the fact that there is an
> implementation based on an unreleased spec or RFC (as my email title seemed
> to indicate).
>
> If a committer comes and say : I'd like to implement rfc-xxx based on the
> public document (spec or rfc), that's very fine with me, because all
> committers have the same level of information and can get involved.   Fwiw,
> that's what usually happens and I haven't seen anything different in Felix
> so far.
>
> If someone comes and say: I'd like to work on some code which will
> eventually become the RI while writing the rfc within the OSGi alliance, I
> don't think that's fine, because what we have in this case is not an
> implementation of something, it's a prototype for designing the spec and
> only OSGi Alliance members who are actually working on the rfc can really
> change the api.
>
> Is that more clear now ?  Am I the only one thinking that if not all
> committers can work on the code, there's a real problem ?
>
>
>
> 2017-01-18 15:29 GMT+01:00 Neil Bartlett :
>
> >
> > > On 18 Jan 2017, at 12:36, Guillaume Nodet  wrote:
> > >
> > > Fwiw, I think Christian was referring to the JAX-RS WHITEBOARD, not the
> > > JAX-RS spec itself.
> > > That one is an RFC from the OSGi Alliance...  RFC-127 afaik.
> >
> > This is pretty much my point. Why raise an issue with the “Whiteboard”
> > half of “JAX-RS Whiteboard” but not with the “JAX-RS” half? Why don’t
> your
> > arguments also apply to JCR specs, or IEEE or W3C specs?
> >
> > Regards,
> > Neil
> >
> > >
> > > 2017-01-18 13:34 GMT+01:00 Neil Bartlett :
> > >
> > >> Christian, your example of JAX-RS Whiteboard is fascinating, because
> > >> JAX-RS was designed by the Expert Groups of the JCP, not by the Apache
> > >> community. The same is true of many of the JavaEE specifications
> > >> implemented within Apache.
> > >>
> > >> So, Apache has always worked pragmatically to implement specifications
> > >> emerging from external standards bodies. It seems odd therefore to
> > single
> > >> out OSGi.
> > >>
> > >> Neil
> > >>
> > >>> On 18 Jan 2017, at 11:25, Christian Schneider <
> ch...@die-schneider.net
> > >
> > >> wrote:
> > >>>
> > >>> I agree with Guillaume that the way the specs are defined is not
> fully
> > >> compatible to the way apache projects are managed.
> > >>> In apache the idea is that the design of a component is defined by
> the
> > >> community.
> > >>>
> > >>> Like in jax-rs-whiteboard .. if it was a pure apache thing then
> changes
> > >> in the interfaces would be proposed on the dev list and agreed on
> there.
> > >>> As the interfaces are part of the spec this is out of direct reach
> for
> > >> the aries community.
> > >>>
> > >>> On the other hand I understand that the final decision about the spec
> > >> has to be at the OSGi alliance and even that only members may decide.
> > >>> So I think this gap can not be fully solved but maybe we can improve
> > it.
> > >>>
> > >>> So what I could imagine is this:
> > >>>
> > >>> - Changes on the spec should be immediately visible to the apache
> > >> community. This could be done using a github repo where the source of
> > the
> > >> spec resides and an automated snapshot build. So all changes could be
> > >> followed directly and the newest spec jars  would always be available.
> > >>> - Protocols of the expert group meetings could be posted to the dev
> > list
> > >>>
> > >>> Both improvements would shorten the feedback loop and give the apache
> > >> community at least more visibility of the spec progress. The community
> > >> could then also directly give feedback to the protocols as well as api
> > >> changes on the dev list. So this would of course still not allow the
> > apache
> > >> community to drive the spec but I think it would be a good compromise.
> > >>>
> > >>> Christian
> > >>>
> > >>> On 18.01.2017 11:59, David Bosschaert wrote:
> >  Hi Guillaume,
> > 
> >  First of all, the OSGi Alliance is a very open standards development
> >  organization. Any organisation can join. RFPs and RFCs are developed
> > in
> > >> the
> >  open, specs are available for free and are free to be implemented by
> > >> anyone.
> > 
> >  There is also an open feedback channel available where everyone can
> > post
> >  feedback, described at https://github.com/osgi/design
> > 
> >  OSGi works very hard in defining specs that are portable and can be
> >  implemented without the need to pay for any licenses or anything of
> > that
> >  sort.
> > 
> >  History has shown that spec implementations 

Re: Implementation of unreleased spec and community

[Richard S. Hall]

On 1/18/17 08:55 , Guillaume Nodet wrote:

2017-01-18 14:29 GMT+01:00 Richard S. Hall :


On 1/18/17 08:22 , Guillaume Nodet wrote:


2017-01-18 13:53 GMT+01:00 Carsten Ziegeler :

Whoever is doing the RI

does it somewhere else and might do a code contribution or not.


Yes, that definitely would avoid the problem.
And I don't think it changes anything from the contributor point of view :
the reason is that it's not really developed openly, as I explained, so
there's definitely no difference with donating the code once the spec has
been released.


There is no difference? Really? Claiming the current approach is not
optimal from a community perspective is certainly not unreasonable, but
saying that the community doesn't benefit at all from having draft
implementations being worked on at Apache seems like a stretch.


Can you outline the benefits then ? Honestly, I don't see the difference
between such an implementation being developed at Apache and the same one
being developed under the same license at github.  At github, I can also
fork, provide PR, raise issues, etc...


Well, at a minimum we get a clearer and simpler IP trail. But at least 
for community members who want to contribute or be exposed to what is 
going on, we don't have to tell them "go someplace else and figure it 
out". So, yes, honestly, I do see a difference.






Not sure

if that is the preferable way. We might end up with not having an
implementation at Apache at all.

The ASF does not care if there is one, multiple or no implementation at

Apache at all afaik.  However, it cares about the way the community work
and that it operates as a meritocracy, which definitely rules out the fact
not all members have access to the same information.


This seems like splitting hairs to me. Even with a complete spec, Apache
members who are also OSGi members will have access to people, processes,
and information than non-OSGi Alliance members will not, giving them an
advantage to implementing and shaping future evolution. There is no way to
level the playing field between the two. Which would be true of any
standards body where you have to be a member to participate.


Shaping future evolution is definitely a privilege of OSGi Alliance members
and again, I have no problem with that part.  The problem is not whether
OSGi members have more information or not, it's whether non OSGi members
have enough information or not to implement a spec.  When the
implementation is used as a play ground for the spec design, that's
definitely not true.


Whether future evolution is long-term (i.e. released specs) or 
short-term (i.e., draft specs), Apache members have no real say in 
shaping them, so I don't see the issue.


You seem to be overly concerned about a case where either a draft spec 
is not available or is somehow out of date. Admittedly, someone without 
access cannot easily hit the target, but it doesn't really matter since 
they can get a new target as soon as the draft is updated. He or she 
still has no input on what the updated draft will be. Oh well.


And even is some OSGi Alliance member and Apache committer does have 
access to unpublished drafts, who cares? It still benefits us a 
community to see the working being done and be exposed to it before the 
draft is updated, if for no other reasons than the ones stated above.


-> richard

Re: Implementation of unreleased spec and community

[Christian Schneider]

To a degree it also applies to any other spec but it is only visible 
when the spec is changing a lot.
As we basically take the jax rs spec as given and static in this project 
there is not much pain in being not in the loop.


For the jax-rs-whiteboard spec it is different as it is more of a moving 
target. I personally would be fine if the OSGi alliance would provide 
snapshots of the spec that reflect the
current status in the expert group. It would be ideal to also have read 
access to the source repo of the spec so you can see the commits, who 
did them and a comment. Ideally a commit in the spec would also point to 
the protocol of the expert group meeting so everyone could read why the 
change was done.


This would give a much better feedback loop than we have now. From my 
point of view this is not absolutely required but it would make the work 
easier and I think it might also lead to a better spec.


Christian

On 18.01.2017 15:29, Neil Bartlett wrote:

On 18 Jan 2017, at 12:36, Guillaume Nodet  wrote:

Fwiw, I think Christian was referring to the JAX-RS WHITEBOARD, not the
JAX-RS spec itself.
That one is an RFC from the OSGi Alliance...  RFC-127 afaik.

This is pretty much my point. Why raise an issue with the “Whiteboard” half of 
“JAX-RS Whiteboard” but not with the “JAX-RS” half? Why don’t your arguments 
also apply to JCR specs, or IEEE or W3C specs?

Regards,
Neil


2017-01-18 13:34 GMT+01:00 Neil Bartlett :


Christian, your example of JAX-RS Whiteboard is fascinating, because
JAX-RS was designed by the Expert Groups of the JCP, not by the Apache
community. The same is true of many of the JavaEE specifications
implemented within Apache.

So, Apache has always worked pragmatically to implement specifications
emerging from external standards bodies. It seems odd therefore to single
out OSGi.

Neil


On 18 Jan 2017, at 11:25, Christian Schneider 

wrote:

I agree with Guillaume that the way the specs are defined is not fully

compatible to the way apache projects are managed.

In apache the idea is that the design of a component is defined by the

community.

Like in jax-rs-whiteboard .. if it was a pure apache thing then changes

in the interfaces would be proposed on the dev list and agreed on there.

As the interfaces are part of the spec this is out of direct reach for

the aries community.

On the other hand I understand that the final decision about the spec

has to be at the OSGi alliance and even that only members may decide.

So I think this gap can not be fully solved but maybe we can improve it.

So what I could imagine is this:

- Changes on the spec should be immediately visible to the apache

community. This could be done using a github repo where the source of the
spec resides and an automated snapshot build. So all changes could be
followed directly and the newest spec jars  would always be available.

- Protocols of the expert group meetings could be posted to the dev list

Both improvements would shorten the feedback loop and give the apache

community at least more visibility of the spec progress. The community
could then also directly give feedback to the protocols as well as api
changes on the dev list. So this would of course still not allow the apache
community to drive the spec but I think it would be a good compromise.

Christian

On 18.01.2017 11:59, David Bosschaert wrote:

Hi Guillaume,

First of all, the OSGi Alliance is a very open standards development
organization. Any organisation can join. RFPs and RFCs are developed in

the

open, specs are available for free and are free to be implemented by

anyone.

There is also an open feedback channel available where everyone can post
feedback, described at https://github.com/osgi/design

OSGi works very hard in defining specs that are portable and can be
implemented without the need to pay for any licenses or anything of that
sort.

History has shown that spec implementations are really quite portable.
Implementation bundles can be mixed from different sources and

everything

just works as long as you use the specced APIs.

Every new spec that is being worked on in OSGi needs, besides the

RFP/RFC

and spec chapter, a Reference Implementation and a Conformance

Testsuite.

Over the past 10 years or so, Reference Implementations have primarily

been

implemented in open source. This has the benefit that everyone can see

what

the implementation is going to be and also it allows everyone to provide
feedback and participate in the implementation. Apache committers have

free

access to the relevant CTs as well.

I think this is all goodness. Or would you rather see that Reference
Implementations are implemented in private?

Best regards,

David


On 18 January 2017 at 10:41, Guillaume Nodet  wrote:


I'm a bit concerned by some subprojects in our communities.

The ASF is supposed to be "community over code", so the very basic

thing

Re: Implementation of unreleased spec and community

[Neil Bartlett]

> On 18 Jan 2017, at 12:36, Guillaume Nodet  wrote:
> 
> Fwiw, I think Christian was referring to the JAX-RS WHITEBOARD, not the
> JAX-RS spec itself.
> That one is an RFC from the OSGi Alliance...  RFC-127 afaik.

This is pretty much my point. Why raise an issue with the “Whiteboard” half of 
“JAX-RS Whiteboard” but not with the “JAX-RS” half? Why don’t your arguments 
also apply to JCR specs, or IEEE or W3C specs?

Regards,
Neil

> 
> 2017-01-18 13:34 GMT+01:00 Neil Bartlett :
> 
>> Christian, your example of JAX-RS Whiteboard is fascinating, because
>> JAX-RS was designed by the Expert Groups of the JCP, not by the Apache
>> community. The same is true of many of the JavaEE specifications
>> implemented within Apache.
>> 
>> So, Apache has always worked pragmatically to implement specifications
>> emerging from external standards bodies. It seems odd therefore to single
>> out OSGi.
>> 
>> Neil
>> 
>>> On 18 Jan 2017, at 11:25, Christian Schneider 
>> wrote:
>>> 
>>> I agree with Guillaume that the way the specs are defined is not fully
>> compatible to the way apache projects are managed.
>>> In apache the idea is that the design of a component is defined by the
>> community.
>>> 
>>> Like in jax-rs-whiteboard .. if it was a pure apache thing then changes
>> in the interfaces would be proposed on the dev list and agreed on there.
>>> As the interfaces are part of the spec this is out of direct reach for
>> the aries community.
>>> 
>>> On the other hand I understand that the final decision about the spec
>> has to be at the OSGi alliance and even that only members may decide.
>>> So I think this gap can not be fully solved but maybe we can improve it.
>>> 
>>> So what I could imagine is this:
>>> 
>>> - Changes on the spec should be immediately visible to the apache
>> community. This could be done using a github repo where the source of the
>> spec resides and an automated snapshot build. So all changes could be
>> followed directly and the newest spec jars  would always be available.
>>> - Protocols of the expert group meetings could be posted to the dev list
>>> 
>>> Both improvements would shorten the feedback loop and give the apache
>> community at least more visibility of the spec progress. The community
>> could then also directly give feedback to the protocols as well as api
>> changes on the dev list. So this would of course still not allow the apache
>> community to drive the spec but I think it would be a good compromise.
>>> 
>>> Christian
>>> 
>>> On 18.01.2017 11:59, David Bosschaert wrote:
 Hi Guillaume,
 
 First of all, the OSGi Alliance is a very open standards development
 organization. Any organisation can join. RFPs and RFCs are developed in
>> the
 open, specs are available for free and are free to be implemented by
>> anyone.
 
 There is also an open feedback channel available where everyone can post
 feedback, described at https://github.com/osgi/design
 
 OSGi works very hard in defining specs that are portable and can be
 implemented without the need to pay for any licenses or anything of that
 sort.
 
 History has shown that spec implementations are really quite portable.
 Implementation bundles can be mixed from different sources and
>> everything
 just works as long as you use the specced APIs.
 
 Every new spec that is being worked on in OSGi needs, besides the
>> RFP/RFC
 and spec chapter, a Reference Implementation and a Conformance
>> Testsuite.
 Over the past 10 years or so, Reference Implementations have primarily
>> been
 implemented in open source. This has the benefit that everyone can see
>> what
 the implementation is going to be and also it allows everyone to provide
 feedback and participate in the implementation. Apache committers have
>> free
 access to the relevant CTs as well.
 
 I think this is all goodness. Or would you rather see that Reference
 Implementations are implemented in private?
 
 Best regards,
 
 David
 
 
 On 18 January 2017 at 10:41, Guillaume Nodet  wrote:
 
> I'm a bit concerned by some subprojects in our communities.
> 
> The ASF is supposed to be "community over code", so the very basic
>> thing
> for a project is that people can get involved.
> 
> However, I see more and more code developped as a reference
>> implementation
> of a spec which is not publicly available, because it's still being
> developed at the OSGi Alliance.  I find that very disturbing because
> there's no way the community can get involved unless they are OSGi
>> Alliance
> members, and that's clearly not acceptable imho.
> 
> Thoughts ?
> Guillaume Nodet
> 
>>> 
>>> 
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>> 
>>> Open Source Architect
>>> http://www.talend.com

Re: Implementation of unreleased spec and community

[Carsten Ziegeler]

Ok, assuming that the OSGi Alliance is not changing its model of
working, what do you propose to do?

Carsten

Guillaume Nodet wrote
> It seems either I have a hard time explaining myself, or you're all blind.
> I'll suppose the first one, so I'll try again.
> 
> Let's say someone comes to aries or felix saying: "i'd like to work on a RI
> for the xxx rfc".  At this point, that's fine if the RFC is kinda frozen.
> Let's imagine it's not, and the api package is changed to play a bit with
> latest EEG phone calls.  Only OSGi Alliance members can freely modify the
> API packages to reflect those changes.  Worse, someone can make a change in
> the API to be latter approved by the OSGi Alliance.
> 
> There's clearly a difference between apache committers who are OSGi members
> and those that are not.  Some of them can make changes, others don't.
> It looks like a problem to me.
> 
> Another concrete example is if someone comes to one ASF project saying:
> "I'd like to contribute this implementation of the RFC.  Btw, the RFC
> document does not yet reflect the changes in the RI, but it will soon".
> 
> Guillaume
> 



 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

It seems either I have a hard time explaining myself, or you're all blind.
I'll suppose the first one, so I'll try again.

Let's say someone comes to aries or felix saying: "i'd like to work on a RI
for the xxx rfc".  At this point, that's fine if the RFC is kinda frozen.
Let's imagine it's not, and the api package is changed to play a bit with
latest EEG phone calls.  Only OSGi Alliance members can freely modify the
API packages to reflect those changes.  Worse, someone can make a change in
the API to be latter approved by the OSGi Alliance.

There's clearly a difference between apache committers who are OSGi members
and those that are not.  Some of them can make changes, others don't.
It looks like a problem to me.

Another concrete example is if someone comes to one ASF project saying:
"I'd like to contribute this implementation of the RFC.  Btw, the RFC
document does not yet reflect the changes in the RI, but it will soon".

Guillaume

2017-01-18 15:15 GMT+01:00 Carsten Ziegeler :

> Guillaume Nodet wrote
> >
> >> There is no difference? Really? Claiming the current approach is not
> >> optimal from a community perspective is certainly not unreasonable, but
> >> saying that the community doesn't benefit at all from having draft
> >> implementations being worked on at Apache seems like a stretch.
> >
> >
> > Can you outline the benefits then ? Honestly, I don't see the difference
> > between such an implementation being developed at Apache and the same one
> > being developed under the same license at github.  At github, I can also
> > fork, provide PR, raise issues, etc...
> >
> Why is github the alternative to Apache? If my work is not valued by the
> Felix community I have no incentive to do it at github. It would rather
> be company internal or maybe at the Eclipse foundation.
> >
> >
> > Shaping future evolution is definitely a privilege of OSGi Alliance
> members
> > and again, I have no problem with that part.  The problem is not whether
> > OSGi members have more information or not, it's whether non OSGi members
> > have enough information or not to implement a spec.  When the
> > implementation is used as a play ground for the spec design, that's
> > definitely not true.
> >
> I've written some of the implementations of the current RFCs and believe me
> the RFC document is all you need. And if not, there are the mentioned
> channels
> to ask for clarifications.
>
>
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Implementation of unreleased spec and community

[Carsten Ziegeler]

Guillaume Nodet wrote
>
>> There is no difference? Really? Claiming the current approach is not
>> optimal from a community perspective is certainly not unreasonable, but
>> saying that the community doesn't benefit at all from having draft
>> implementations being worked on at Apache seems like a stretch.
> 
> 
> Can you outline the benefits then ? Honestly, I don't see the difference
> between such an implementation being developed at Apache and the same one
> being developed under the same license at github.  At github, I can also
> fork, provide PR, raise issues, etc...
> 
Why is github the alternative to Apache? If my work is not valued by the
Felix community I have no incentive to do it at github. It would rather
be company internal or maybe at the Eclipse foundation.
> 
> 
> Shaping future evolution is definitely a privilege of OSGi Alliance members
> and again, I have no problem with that part.  The problem is not whether
> OSGi members have more information or not, it's whether non OSGi members
> have enough information or not to implement a spec.  When the
> implementation is used as a play ground for the spec design, that's
> definitely not true.
> 
I've written some of the implementations of the current RFCs and believe me
the RFC document is all you need. And if not, there are the mentioned
channels
to ask for clarifications.


Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

2017-01-18 14:29 GMT+01:00 Richard S. Hall :

> On 1/18/17 08:22 , Guillaume Nodet wrote:
>
>> 2017-01-18 13:53 GMT+01:00 Carsten Ziegeler :
>>
>> Whoever is doing the RI
>>> does it somewhere else and might do a code contribution or not.
>>>
>>
>> Yes, that definitely would avoid the problem.
>> And I don't think it changes anything from the contributor point of view :
>> the reason is that it's not really developed openly, as I explained, so
>> there's definitely no difference with donating the code once the spec has
>> been released.
>>
>
> There is no difference? Really? Claiming the current approach is not
> optimal from a community perspective is certainly not unreasonable, but
> saying that the community doesn't benefit at all from having draft
> implementations being worked on at Apache seems like a stretch.


Can you outline the benefits then ? Honestly, I don't see the difference
between such an implementation being developed at Apache and the same one
being developed under the same license at github.  At github, I can also
fork, provide PR, raise issues, etc...


>
>
>
>> Not sure
>>> if that is the preferable way. We might end up with not having an
>>> implementation at Apache at all.
>>>
>>> The ASF does not care if there is one, multiple or no implementation at
>> Apache at all afaik.  However, it cares about the way the community work
>> and that it operates as a meritocracy, which definitely rules out the fact
>> not all members have access to the same information.
>>
>
> This seems like splitting hairs to me. Even with a complete spec, Apache
> members who are also OSGi members will have access to people, processes,
> and information than non-OSGi Alliance members will not, giving them an
> advantage to implementing and shaping future evolution. There is no way to
> level the playing field between the two. Which would be true of any
> standards body where you have to be a member to participate.


Shaping future evolution is definitely a privilege of OSGi Alliance members
and again, I have no problem with that part.  The problem is not whether
OSGi members have more information or not, it's whether non OSGi members
have enough information or not to implement a spec.  When the
implementation is used as a play ground for the spec design, that's
definitely not true.


>
>
> -> richard
>
>
>


-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

2017-01-18 11:59 GMT+01:00 David Bosschaert :

> Hi Guillaume,
>
> First of all, the OSGi Alliance is a very open standards development
> organization. Any organisation can join. RFPs and RFCs are developed in the
> open, specs are available for free and are free to be implemented by
> anyone.
>
> There is also an open feedback channel available where everyone can post
> feedback, described at https://github.com/osgi/design
>
> OSGi works very hard in defining specs that are portable and can be
> implemented without the need to pay for any licenses or anything of that
> sort.
>
> History has shown that spec implementations are really quite portable.
> Implementation bundles can be mixed from different sources and everything
> just works as long as you use the specced APIs.
>
> Every new spec that is being worked on in OSGi needs, besides the RFP/RFC
> and spec chapter, a Reference Implementation and a Conformance Testsuite.
> Over the past 10 years or so, Reference Implementations have primarily been
> implemented in open source. This has the benefit that everyone can see what
> the implementation is going to be and also it allows everyone to provide
> feedback and participate in the implementation.


That's very fine.  Fwiw, I really don't think this is advertised anywhere.
I mean, I'm quite sure there's no way you can know where the RI is being
developed by looking at the public documents from the OSGi Alliance.  So
while the goal is interesting, I doubt a lot of non members know where the
RI is being developed.


> Apache committers have free
> access to the relevant CTs as well.
>
> I think this is all goodness. Or would you rather see that Reference
> Implementations are implemented in private?
>

Definitely not.  Though, for myself, if the RI is LGPL, I won't use it, so
it does not matter to me.  However, a ASL2 / BSD licensed RI is very
interesting for users.  But that has nothing to do with *where* this RI is
developed.  You can perfectly develop an ASL2 RI at github.
If you want to do it at Apache, you need to follow its rules.


>
> Best regards,
>
> David
>
>
> On 18 January 2017 at 10:41, Guillaume Nodet  wrote:
>
> > I'm a bit concerned by some subprojects in our communities.
> >
> > The ASF is supposed to be "community over code", so the very basic thing
> > for a project is that people can get involved.
> >
> > However, I see more and more code developped as a reference
> implementation
> > of a spec which is not publicly available, because it's still being
> > developed at the OSGi Alliance.  I find that very disturbing because
> > there's no way the community can get involved unless they are OSGi
> Alliance
> > members, and that's clearly not acceptable imho.
> >
> > Thoughts ?
> > Guillaume Nodet
> >
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Implementation of unreleased spec and community

[Richard S. Hall]

On 1/18/17 08:22 , Guillaume Nodet wrote:

2017-01-18 13:53 GMT+01:00 Carsten Ziegeler :


Whoever is doing the RI
does it somewhere else and might do a code contribution or not.


Yes, that definitely would avoid the problem.
And I don't think it changes anything from the contributor point of view :
the reason is that it's not really developed openly, as I explained, so
there's definitely no difference with donating the code once the spec has
been released.


There is no difference? Really? Claiming the current approach is not 
optimal from a community perspective is certainly not unreasonable, but 
saying that the community doesn't benefit at all from having draft 
implementations being worked on at Apache seems like a stretch.





Not sure
if that is the preferable way. We might end up with not having an
implementation at Apache at all.


The ASF does not care if there is one, multiple or no implementation at
Apache at all afaik.  However, it cares about the way the community work
and that it operates as a meritocracy, which definitely rules out the fact
not all members have access to the same information.


This seems like splitting hairs to me. Even with a complete spec, Apache 
members who are also OSGi members will have access to people, processes, 
and information than non-OSGi Alliance members will not, giving them an 
advantage to implementing and shaping future evolution. There is no way 
to level the playing field between the two. Which would be true of any 
standards body where you have to be a member to participate.


-> richard

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

2017-01-18 13:53 GMT+01:00 Carsten Ziegeler :

> Guillaume Nodet wrote
> >
> > Again, I'm talking about using Apache to develop the will-be reference
> > implementation of the being-designed spec.  When the rfc is  undergoing
> > changes, the RI, as you say, is an experimental project to make sure the
> > RFC properly address all problems and can be turned into a spec.   The
> > information needed to get involved in such a moving target is not
> available
> > to the Apache community.  Again, I've no problem if someone wants to
> > develop an implementation of a publicly available spec, but that's not
> what
> > I'm discussing here.
> >
> > And I don't think the OSGi Alliance want to have an open participation
> into
> > the spec design process, and that's perfectly fine with me.  If I'm
> wrong,
> > then using public mailing lists and avoiding phone calls and f2f meetings
> > is the way to go, such as we do at the ASF.
> >
> We should not get into a discussion here how the OSGi Alliance should
> work.


We definitely have to discuss how the way the OSGi Alliance operates
affects the ASF projects.  I haven't advocated any change on the OSGi
Alliance, that's definitely not our business.


>
> The other option we have is that we don't do any implementation of an
> RFC here at Apache and wait for the final spec.


The problem is not the fact that it's an RFC or a draft.  The problem is
the fact that the implementation is the input for changes into the spec.
If the implementation only follows public changes, that would be fine.


> Whoever is doing the RI
> does it somewhere else and might do a code contribution or not.


Yes, that definitely would avoid the problem.
And I don't think it changes anything from the contributor point of view :
the reason is that it's not really developed openly, as I explained, so
there's definitely no difference with donating the code once the spec has
been released.


> Not sure
> if that is the preferable way. We might end up with not having an
> implementation at Apache at all.
>

The ASF does not care if there is one, multiple or no implementation at
Apache at all afaik.  However, it cares about the way the community work
and that it operates as a meritocracy, which definitely rules out the fact
not all members have access to the same information.


>
>  Regards
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Implementation of unreleased spec and community

[Carsten Ziegeler]

Guillaume Nodet wrote
> 
> Again, I'm talking about using Apache to develop the will-be reference
> implementation of the being-designed spec.  When the rfc is  undergoing
> changes, the RI, as you say, is an experimental project to make sure the
> RFC properly address all problems and can be turned into a spec.   The
> information needed to get involved in such a moving target is not available
> to the Apache community.  Again, I've no problem if someone wants to
> develop an implementation of a publicly available spec, but that's not what
> I'm discussing here.
> 
> And I don't think the OSGi Alliance want to have an open participation into
> the spec design process, and that's perfectly fine with me.  If I'm wrong,
> then using public mailing lists and avoiding phone calls and f2f meetings
> is the way to go, such as we do at the ASF.
> 
We should not get into a discussion here how the OSGi Alliance should work.

The other option we have is that we don't do any implementation of an
RFC here at Apache and wait for the final spec. Whoever is doing the RI
does it somewhere else and might do a code contribution or not. Not sure
if that is the preferable way. We might end up with not having an
implementation at Apache at all.

 Regards

Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Implementation of unreleased spec and community

[Bram Pouwelse]

> I'm not talking about developing an implementation of a publicly released 
> specification.
I have absolutely no problem with that of course.

How is that different from developing an implementation for a publicly
released DRAFT specification? In both cases you create an implementation
for something that was specced outside of the Apache community.

On Wed, Jan 18, 2017 at 1:43 PM Guillaume Nodet  wrote:

> RFC-217 sorry
>https://github.com/osgi/design/tree/master/rfcs/rfc0217
>
>
>
> 2017-01-18 13:36 GMT+01:00 Guillaume Nodet :
>
> > Fwiw, I think Christian was referring to the JAX-RS WHITEBOARD, not the
> > JAX-RS spec itself.
> > That one is an RFC from the OSGi Alliance...  RFC-127 afaik.
> >
> > 2017-01-18 13:34 GMT+01:00 Neil Bartlett :
> >
> >> Christian, your example of JAX-RS Whiteboard is fascinating, because
> >> JAX-RS was designed by the Expert Groups of the JCP, not by the Apache
> >> community. The same is true of many of the JavaEE specifications
> >> implemented within Apache.
> >>
> >> So, Apache has always worked pragmatically to implement specifications
> >> emerging from external standards bodies. It seems odd therefore to
> single
> >> out OSGi.
> >>
> >> Neil
> >>
> >> > On 18 Jan 2017, at 11:25, Christian Schneider <
> ch...@die-schneider.net>
> >> wrote:
> >> >
> >> > I agree with Guillaume that the way the specs are defined is not fully
> >> compatible to the way apache projects are managed.
> >> > In apache the idea is that the design of a component is defined by the
> >> community.
> >> >
> >> > Like in jax-rs-whiteboard .. if it was a pure apache thing then
> changes
> >> in the interfaces would be proposed on the dev list and agreed on there.
> >> > As the interfaces are part of the spec this is out of direct reach for
> >> the aries community.
> >> >
> >> > On the other hand I understand that the final decision about the spec
> >> has to be at the OSGi alliance and even that only members may decide.
> >> > So I think this gap can not be fully solved but maybe we can improve
> it.
> >> >
> >> > So what I could imagine is this:
> >> >
> >> > - Changes on the spec should be immediately visible to the apache
> >> community. This could be done using a github repo where the source of
> the
> >> spec resides and an automated snapshot build. So all changes could be
> >> followed directly and the newest spec jars  would always be available.
> >> > - Protocols of the expert group meetings could be posted to the dev
> list
> >> >
> >> > Both improvements would shorten the feedback loop and give the apache
> >> community at least more visibility of the spec progress. The community
> >> could then also directly give feedback to the protocols as well as api
> >> changes on the dev list. So this would of course still not allow the
> apache
> >> community to drive the spec but I think it would be a good compromise.
> >> >
> >> > Christian
> >> >
> >> > On 18.01.2017 11:59, David Bosschaert wrote:
> >> >> Hi Guillaume,
> >> >>
> >> >> First of all, the OSGi Alliance is a very open standards development
> >> >> organization. Any organisation can join. RFPs and RFCs are developed
> >> in the
> >> >> open, specs are available for free and are free to be implemented by
> >> anyone.
> >> >>
> >> >> There is also an open feedback channel available where everyone can
> >> post
> >> >> feedback, described at https://github.com/osgi/design
> >> >>
> >> >> OSGi works very hard in defining specs that are portable and can be
> >> >> implemented without the need to pay for any licenses or anything of
> >> that
> >> >> sort.
> >> >>
> >> >> History has shown that spec implementations are really quite
> portable.
> >> >> Implementation bundles can be mixed from different sources and
> >> everything
> >> >> just works as long as you use the specced APIs.
> >> >>
> >> >> Every new spec that is being worked on in OSGi needs, besides the
> >> RFP/RFC
> >> >> and spec chapter, a Reference Implementation and a Conformance
> >> Testsuite.
> >> >> Over the past 10 years or so, Reference Implementations have
> primarily
> >> been
> >> >> implemented in open source. This has the benefit that everyone can
> see
> >> what
> >> >> the implementation is going to be and also it allows everyone to
> >> provide
> >> >> feedback and participate in the implementation. Apache committers
> have
> >> free
> >> >> access to the relevant CTs as well.
> >> >>
> >> >> I think this is all goodness. Or would you rather see that Reference
> >> >> Implementations are implemented in private?
> >> >>
> >> >> Best regards,
> >> >>
> >> >> David
> >> >>
> >> >>
> >> >> On 18 January 2017 at 10:41, Guillaume Nodet 
> >> wrote:
> >> >>
> >> >>> I'm a bit concerned by some subprojects in our communities.
> >> >>>
> >> >>> The ASF is supposed to be "community over code", so the very basic
> >> thing
> >> >>> for a project is that people can get involved.
> >> 

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

RFC-217 sorry
   https://github.com/osgi/design/tree/master/rfcs/rfc0217



2017-01-18 13:36 GMT+01:00 Guillaume Nodet :

> Fwiw, I think Christian was referring to the JAX-RS WHITEBOARD, not the
> JAX-RS spec itself.
> That one is an RFC from the OSGi Alliance...  RFC-127 afaik.
>
> 2017-01-18 13:34 GMT+01:00 Neil Bartlett :
>
>> Christian, your example of JAX-RS Whiteboard is fascinating, because
>> JAX-RS was designed by the Expert Groups of the JCP, not by the Apache
>> community. The same is true of many of the JavaEE specifications
>> implemented within Apache.
>>
>> So, Apache has always worked pragmatically to implement specifications
>> emerging from external standards bodies. It seems odd therefore to single
>> out OSGi.
>>
>> Neil
>>
>> > On 18 Jan 2017, at 11:25, Christian Schneider 
>> wrote:
>> >
>> > I agree with Guillaume that the way the specs are defined is not fully
>> compatible to the way apache projects are managed.
>> > In apache the idea is that the design of a component is defined by the
>> community.
>> >
>> > Like in jax-rs-whiteboard .. if it was a pure apache thing then changes
>> in the interfaces would be proposed on the dev list and agreed on there.
>> > As the interfaces are part of the spec this is out of direct reach for
>> the aries community.
>> >
>> > On the other hand I understand that the final decision about the spec
>> has to be at the OSGi alliance and even that only members may decide.
>> > So I think this gap can not be fully solved but maybe we can improve it.
>> >
>> > So what I could imagine is this:
>> >
>> > - Changes on the spec should be immediately visible to the apache
>> community. This could be done using a github repo where the source of the
>> spec resides and an automated snapshot build. So all changes could be
>> followed directly and the newest spec jars  would always be available.
>> > - Protocols of the expert group meetings could be posted to the dev list
>> >
>> > Both improvements would shorten the feedback loop and give the apache
>> community at least more visibility of the spec progress. The community
>> could then also directly give feedback to the protocols as well as api
>> changes on the dev list. So this would of course still not allow the apache
>> community to drive the spec but I think it would be a good compromise.
>> >
>> > Christian
>> >
>> > On 18.01.2017 11:59, David Bosschaert wrote:
>> >> Hi Guillaume,
>> >>
>> >> First of all, the OSGi Alliance is a very open standards development
>> >> organization. Any organisation can join. RFPs and RFCs are developed
>> in the
>> >> open, specs are available for free and are free to be implemented by
>> anyone.
>> >>
>> >> There is also an open feedback channel available where everyone can
>> post
>> >> feedback, described at https://github.com/osgi/design
>> >>
>> >> OSGi works very hard in defining specs that are portable and can be
>> >> implemented without the need to pay for any licenses or anything of
>> that
>> >> sort.
>> >>
>> >> History has shown that spec implementations are really quite portable.
>> >> Implementation bundles can be mixed from different sources and
>> everything
>> >> just works as long as you use the specced APIs.
>> >>
>> >> Every new spec that is being worked on in OSGi needs, besides the
>> RFP/RFC
>> >> and spec chapter, a Reference Implementation and a Conformance
>> Testsuite.
>> >> Over the past 10 years or so, Reference Implementations have primarily
>> been
>> >> implemented in open source. This has the benefit that everyone can see
>> what
>> >> the implementation is going to be and also it allows everyone to
>> provide
>> >> feedback and participate in the implementation. Apache committers have
>> free
>> >> access to the relevant CTs as well.
>> >>
>> >> I think this is all goodness. Or would you rather see that Reference
>> >> Implementations are implemented in private?
>> >>
>> >> Best regards,
>> >>
>> >> David
>> >>
>> >>
>> >> On 18 January 2017 at 10:41, Guillaume Nodet 
>> wrote:
>> >>
>> >>> I'm a bit concerned by some subprojects in our communities.
>> >>>
>> >>> The ASF is supposed to be "community over code", so the very basic
>> thing
>> >>> for a project is that people can get involved.
>> >>>
>> >>> However, I see more and more code developped as a reference
>> implementation
>> >>> of a spec which is not publicly available, because it's still being
>> >>> developed at the OSGi Alliance.  I find that very disturbing because
>> >>> there's no way the community can get involved unless they are OSGi
>> Alliance
>> >>> members, and that's clearly not acceptable imho.
>> >>>
>> >>> Thoughts ?
>> >>> Guillaume Nodet
>> >>>
>> >
>> >
>> > --
>> > Christian Schneider
>> > http://www.liquid-reality.de
>> >
>> > Open Source Architect
>> > http://www.talend.com
>> >
>>
>>
>
>
> --
> 
> Guillaume Nodet
> 
> Red 

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

2017-01-18 13:22 GMT+01:00 Neil Bartlett :

> Guillaume, you seem to be working from out of date information. All RFPs
> and RFCs are publicly available, including those that are still being
> developed. They are here: https://github.com/osgi/design/. This has been
> the case for at least four years now.
>
> Given this, I don’t see any impediment to the Apache community, or any
> other person, in implementing any OSGi specification or
> specification-in-progress.
>

I am very well aware of that fact, thx.


>
> Design of the specifications is properly reserved to OSGi members, i.e.
> organisations that have signed the membership agreement, because this gives
> confidence in the IP contained in those specifications. However it is not
> necessary to be involved in that design process in order to write an
> implementation. Occasionally an implementer will find a flaw such that an
> RFC cannot be implemented, but that information can be fed back to the OSGi
> members, and this is why OSGi specifications *must* have a functioning RI
> before they can be considered complete. On the other hand, if you merely
> have better ideas about the way the specification should be designed, then
> join the Alliance and get involved.
>

Again, I'm talking about using Apache to develop the will-be reference
implementation of the being-designed spec.  When the rfc is  undergoing
changes, the RI, as you say, is an experimental project to make sure the
RFC properly address all problems and can be turned into a spec.   The
information needed to get involved in such a moving target is not available
to the Apache community.  Again, I've no problem if someone wants to
develop an implementation of a publicly available spec, but that's not what
I'm discussing here.

And I don't think the OSGi Alliance want to have an open participation into
the spec design process, and that's perfectly fine with me.  If I'm wrong,
then using public mailing lists and avoiding phone calls and f2f meetings
is the way to go, such as we do at the ASF.


>
> Regards,
> Neil
>
> > On 18 Jan 2017, at 11:21, Guillaume Nodet  wrote:
> >
> > 2017-01-18 11:46 GMT+01:00 Neil Bartlett >:
> >
> >> Guillaume,
> >>
> >> All OSGi specifications in progress are publicly visible, so in what
> sense
> >> are Apache community members unable to be involved in the development of
> >> the RIs?
> >>
> >
> > I'm not talking about developing an implementation of a publicly released
> > specification.  I have absolutely no problem with that of course.  In
> such
> > a case, everyone is on the same ground and can go read the spec, afaik,
> the
> > OSGi Alliance also gives access to the TCK.
> >
> > I'm talking about developing an implementation of an RFC which is still
> > being developed.  The RFC is developed by OSGi Alliance members during
> > phone calls or face to face meetings.   Someone not a member of the OSGi
> > Alliance can't participate in the design process and can't even have
> access
> > to those documents.  I don't see how all community members can be treated
> > equally in such a situation.  A back channel where people can submit
> > feedback is definitely not the same as being part of the design process.
> > I'm not advocating that the ASF has to be part of the process, that's
> > something for the OSGi Alliance to decide.  However, if the ASF
> committers
> > can't be part of it, I don't how an implementation of a design in
> progress
> > can be done correctly inside an ASF project.
> >
> >
> >
> >>
> >> Regards,
> >> Neil
> >>
> >>> On 18 Jan 2017, at 10:41, Guillaume Nodet  wrote:
> >>>
> >>> I'm a bit concerned by some subprojects in our communities.
> >>>
> >>> The ASF is supposed to be "community over code", so the very basic
> thing
> >>> for a project is that people can get involved.
> >>>
> >>> However, I see more and more code developped as a reference
> >> implementation
> >>> of a spec which is not publicly available, because it's still being
> >>> developed at the OSGi Alliance.  I find that very disturbing because
> >>> there's no way the community can get involved unless they are OSGi
> >> Alliance
> >>> members, and that's clearly not acceptable imho.
> >>>
> >>> Thoughts ?
> >>> Guillaume Nodet
> >>
> >>
> >
> >
> > --
> > 
> > Guillaume Nodet
> > 
> > Red Hat, Open Source Integration
> >
> > Email: gno...@redhat.com 
> > Web: http://fusesource.com 
> > Blog: http://gnodet.blogspot.com/ 
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

Fwiw, I think Christian was referring to the JAX-RS WHITEBOARD, not the
JAX-RS spec itself.
That one is an RFC from the OSGi Alliance...  RFC-127 afaik.

2017-01-18 13:34 GMT+01:00 Neil Bartlett :

> Christian, your example of JAX-RS Whiteboard is fascinating, because
> JAX-RS was designed by the Expert Groups of the JCP, not by the Apache
> community. The same is true of many of the JavaEE specifications
> implemented within Apache.
>
> So, Apache has always worked pragmatically to implement specifications
> emerging from external standards bodies. It seems odd therefore to single
> out OSGi.
>
> Neil
>
> > On 18 Jan 2017, at 11:25, Christian Schneider 
> wrote:
> >
> > I agree with Guillaume that the way the specs are defined is not fully
> compatible to the way apache projects are managed.
> > In apache the idea is that the design of a component is defined by the
> community.
> >
> > Like in jax-rs-whiteboard .. if it was a pure apache thing then changes
> in the interfaces would be proposed on the dev list and agreed on there.
> > As the interfaces are part of the spec this is out of direct reach for
> the aries community.
> >
> > On the other hand I understand that the final decision about the spec
> has to be at the OSGi alliance and even that only members may decide.
> > So I think this gap can not be fully solved but maybe we can improve it.
> >
> > So what I could imagine is this:
> >
> > - Changes on the spec should be immediately visible to the apache
> community. This could be done using a github repo where the source of the
> spec resides and an automated snapshot build. So all changes could be
> followed directly and the newest spec jars  would always be available.
> > - Protocols of the expert group meetings could be posted to the dev list
> >
> > Both improvements would shorten the feedback loop and give the apache
> community at least more visibility of the spec progress. The community
> could then also directly give feedback to the protocols as well as api
> changes on the dev list. So this would of course still not allow the apache
> community to drive the spec but I think it would be a good compromise.
> >
> > Christian
> >
> > On 18.01.2017 11:59, David Bosschaert wrote:
> >> Hi Guillaume,
> >>
> >> First of all, the OSGi Alliance is a very open standards development
> >> organization. Any organisation can join. RFPs and RFCs are developed in
> the
> >> open, specs are available for free and are free to be implemented by
> anyone.
> >>
> >> There is also an open feedback channel available where everyone can post
> >> feedback, described at https://github.com/osgi/design
> >>
> >> OSGi works very hard in defining specs that are portable and can be
> >> implemented without the need to pay for any licenses or anything of that
> >> sort.
> >>
> >> History has shown that spec implementations are really quite portable.
> >> Implementation bundles can be mixed from different sources and
> everything
> >> just works as long as you use the specced APIs.
> >>
> >> Every new spec that is being worked on in OSGi needs, besides the
> RFP/RFC
> >> and spec chapter, a Reference Implementation and a Conformance
> Testsuite.
> >> Over the past 10 years or so, Reference Implementations have primarily
> been
> >> implemented in open source. This has the benefit that everyone can see
> what
> >> the implementation is going to be and also it allows everyone to provide
> >> feedback and participate in the implementation. Apache committers have
> free
> >> access to the relevant CTs as well.
> >>
> >> I think this is all goodness. Or would you rather see that Reference
> >> Implementations are implemented in private?
> >>
> >> Best regards,
> >>
> >> David
> >>
> >>
> >> On 18 January 2017 at 10:41, Guillaume Nodet  wrote:
> >>
> >>> I'm a bit concerned by some subprojects in our communities.
> >>>
> >>> The ASF is supposed to be "community over code", so the very basic
> thing
> >>> for a project is that people can get involved.
> >>>
> >>> However, I see more and more code developped as a reference
> implementation
> >>> of a spec which is not publicly available, because it's still being
> >>> developed at the OSGi Alliance.  I find that very disturbing because
> >>> there's no way the community can get involved unless they are OSGi
> Alliance
> >>> members, and that's clearly not acceptable imho.
> >>>
> >>> Thoughts ?
> >>> Guillaume Nodet
> >>>
> >
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
>
>


-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Implementation of unreleased spec and community

[Neil Bartlett]

Christian, your example of JAX-RS Whiteboard is fascinating, because JAX-RS was 
designed by the Expert Groups of the JCP, not by the Apache community. The same 
is true of many of the JavaEE specifications implemented within Apache.

So, Apache has always worked pragmatically to implement specifications emerging 
from external standards bodies. It seems odd therefore to single out OSGi.

Neil

> On 18 Jan 2017, at 11:25, Christian Schneider  wrote:
> 
> I agree with Guillaume that the way the specs are defined is not fully 
> compatible to the way apache projects are managed.
> In apache the idea is that the design of a component is defined by the 
> community.
> 
> Like in jax-rs-whiteboard .. if it was a pure apache thing then changes in 
> the interfaces would be proposed on the dev list and agreed on there.
> As the interfaces are part of the spec this is out of direct reach for the 
> aries community.
> 
> On the other hand I understand that the final decision about the spec has to 
> be at the OSGi alliance and even that only members may decide.
> So I think this gap can not be fully solved but maybe we can improve it.
> 
> So what I could imagine is this:
> 
> - Changes on the spec should be immediately visible to the apache community. 
> This could be done using a github repo where the source of the spec resides 
> and an automated snapshot build. So all changes could be followed directly 
> and the newest spec jars  would always be available.
> - Protocols of the expert group meetings could be posted to the dev list
> 
> Both improvements would shorten the feedback loop and give the apache 
> community at least more visibility of the spec progress. The community could 
> then also directly give feedback to the protocols as well as api changes on 
> the dev list. So this would of course still not allow the apache community to 
> drive the spec but I think it would be a good compromise.
> 
> Christian
> 
> On 18.01.2017 11:59, David Bosschaert wrote:
>> Hi Guillaume,
>> 
>> First of all, the OSGi Alliance is a very open standards development
>> organization. Any organisation can join. RFPs and RFCs are developed in the
>> open, specs are available for free and are free to be implemented by anyone.
>> 
>> There is also an open feedback channel available where everyone can post
>> feedback, described at https://github.com/osgi/design
>> 
>> OSGi works very hard in defining specs that are portable and can be
>> implemented without the need to pay for any licenses or anything of that
>> sort.
>> 
>> History has shown that spec implementations are really quite portable.
>> Implementation bundles can be mixed from different sources and everything
>> just works as long as you use the specced APIs.
>> 
>> Every new spec that is being worked on in OSGi needs, besides the RFP/RFC
>> and spec chapter, a Reference Implementation and a Conformance Testsuite.
>> Over the past 10 years or so, Reference Implementations have primarily been
>> implemented in open source. This has the benefit that everyone can see what
>> the implementation is going to be and also it allows everyone to provide
>> feedback and participate in the implementation. Apache committers have free
>> access to the relevant CTs as well.
>> 
>> I think this is all goodness. Or would you rather see that Reference
>> Implementations are implemented in private?
>> 
>> Best regards,
>> 
>> David
>> 
>> 
>> On 18 January 2017 at 10:41, Guillaume Nodet  wrote:
>> 
>>> I'm a bit concerned by some subprojects in our communities.
>>> 
>>> The ASF is supposed to be "community over code", so the very basic thing
>>> for a project is that people can get involved.
>>> 
>>> However, I see more and more code developped as a reference implementation
>>> of a spec which is not publicly available, because it's still being
>>> developed at the OSGi Alliance.  I find that very disturbing because
>>> there's no way the community can get involved unless they are OSGi Alliance
>>> members, and that's clearly not acceptable imho.
>>> 
>>> Thoughts ?
>>> Guillaume Nodet
>>> 
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 

Re: Implementation of unreleased spec and community

[Neil Bartlett]

Guillaume, you seem to be working from out of date information. All RFPs and 
RFCs are publicly available, including those that are still being developed. 
They are here: https://github.com/osgi/design/. This has been the case for at 
least four years now.

Given this, I don’t see any impediment to the Apache community, or any other 
person, in implementing any OSGi specification or specification-in-progress.

Design of the specifications is properly reserved to OSGi members, i.e. 
organisations that have signed the membership agreement, because this gives 
confidence in the IP contained in those specifications. However it is not 
necessary to be involved in that design process in order to write an 
implementation. Occasionally an implementer will find a flaw such that an RFC 
cannot be implemented, but that information can be fed back to the OSGi 
members, and this is why OSGi specifications *must* have a functioning RI 
before they can be considered complete. On the other hand, if you merely have 
better ideas about the way the specification should be designed, then join the 
Alliance and get involved.

Regards,
Neil

> On 18 Jan 2017, at 11:21, Guillaume Nodet  wrote:
> 
> 2017-01-18 11:46 GMT+01:00 Neil Bartlett  >:
> 
>> Guillaume,
>> 
>> All OSGi specifications in progress are publicly visible, so in what sense
>> are Apache community members unable to be involved in the development of
>> the RIs?
>> 
> 
> I'm not talking about developing an implementation of a publicly released
> specification.  I have absolutely no problem with that of course.  In such
> a case, everyone is on the same ground and can go read the spec, afaik, the
> OSGi Alliance also gives access to the TCK.
> 
> I'm talking about developing an implementation of an RFC which is still
> being developed.  The RFC is developed by OSGi Alliance members during
> phone calls or face to face meetings.   Someone not a member of the OSGi
> Alliance can't participate in the design process and can't even have access
> to those documents.  I don't see how all community members can be treated
> equally in such a situation.  A back channel where people can submit
> feedback is definitely not the same as being part of the design process.
> I'm not advocating that the ASF has to be part of the process, that's
> something for the OSGi Alliance to decide.  However, if the ASF committers
> can't be part of it, I don't how an implementation of a design in progress
> can be done correctly inside an ASF project.
> 
> 
> 
>> 
>> Regards,
>> Neil
>> 
>>> On 18 Jan 2017, at 10:41, Guillaume Nodet  wrote:
>>> 
>>> I'm a bit concerned by some subprojects in our communities.
>>> 
>>> The ASF is supposed to be "community over code", so the very basic thing
>>> for a project is that people can get involved.
>>> 
>>> However, I see more and more code developped as a reference
>> implementation
>>> of a spec which is not publicly available, because it's still being
>>> developed at the OSGi Alliance.  I find that very disturbing because
>>> there's no way the community can get involved unless they are OSGi
>> Alliance
>>> members, and that's clearly not acceptable imho.
>>> 
>>> Thoughts ?
>>> Guillaume Nodet
>> 
>> 
> 
> 
> -- 
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
> 
> Email: gno...@redhat.com 
> Web: http://fusesource.com 
> Blog: http://gnodet.blogspot.com/ 

Re: Implementation of unreleased spec and community

[Christian Schneider]

I agree with Guillaume that the way the specs are defined is not fully 
compatible to the way apache projects are managed.
In apache the idea is that the design of a component is defined by the 
community.


Like in jax-rs-whiteboard .. if it was a pure apache thing then changes 
in the interfaces would be proposed on the dev list and agreed on there.
As the interfaces are part of the spec this is out of direct reach for 
the aries community.


On the other hand I understand that the final decision about the spec 
has to be at the OSGi alliance and even that only members may decide.

So I think this gap can not be fully solved but maybe we can improve it.

So what I could imagine is this:

- Changes on the spec should be immediately visible to the apache 
community. This could be done using a github repo where the source of 
the spec resides and an automated snapshot build. So all changes could 
be followed directly and the newest spec jars  would always be available.

- Protocols of the expert group meetings could be posted to the dev list

Both improvements would shorten the feedback loop and give the apache 
community at least more visibility of the spec progress. The community 
could then also directly give feedback to the protocols as well as api 
changes on the dev list. So this would of course still not allow the 
apache community to drive the spec but I think it would be a good 
compromise.


Christian

On 18.01.2017 11:59, David Bosschaert wrote:

Hi Guillaume,

First of all, the OSGi Alliance is a very open standards development
organization. Any organisation can join. RFPs and RFCs are developed in the
open, specs are available for free and are free to be implemented by anyone.

There is also an open feedback channel available where everyone can post
feedback, described at https://github.com/osgi/design

OSGi works very hard in defining specs that are portable and can be
implemented without the need to pay for any licenses or anything of that
sort.

History has shown that spec implementations are really quite portable.
Implementation bundles can be mixed from different sources and everything
just works as long as you use the specced APIs.

Every new spec that is being worked on in OSGi needs, besides the RFP/RFC
and spec chapter, a Reference Implementation and a Conformance Testsuite.
Over the past 10 years or so, Reference Implementations have primarily been
implemented in open source. This has the benefit that everyone can see what
the implementation is going to be and also it allows everyone to provide
feedback and participate in the implementation. Apache committers have free
access to the relevant CTs as well.

I think this is all goodness. Or would you rather see that Reference
Implementations are implemented in private?

Best regards,

David


On 18 January 2017 at 10:41, Guillaume Nodet  wrote:


I'm a bit concerned by some subprojects in our communities.

The ASF is supposed to be "community over code", so the very basic thing
for a project is that people can get involved.

However, I see more and more code developped as a reference implementation
of a spec which is not publicly available, because it's still being
developed at the OSGi Alliance.  I find that very disturbing because
there's no way the community can get involved unless they are OSGi Alliance
members, and that's clearly not acceptable imho.

Thoughts ?
Guillaume Nodet




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Implementation of unreleased spec and community

[Guillaume Nodet]

2017-01-18 11:46 GMT+01:00 Neil Bartlett :

> Guillaume,
>
> All OSGi specifications in progress are publicly visible, so in what sense
> are Apache community members unable to be involved in the development of
> the RIs?
>

I'm not talking about developing an implementation of a publicly released
specification.  I have absolutely no problem with that of course.  In such
a case, everyone is on the same ground and can go read the spec, afaik, the
OSGi Alliance also gives access to the TCK.

I'm talking about developing an implementation of an RFC which is still
being developed.  The RFC is developed by OSGi Alliance members during
phone calls or face to face meetings.   Someone not a member of the OSGi
Alliance can't participate in the design process and can't even have access
to those documents.  I don't see how all community members can be treated
equally in such a situation.  A back channel where people can submit
feedback is definitely not the same as being part of the design process.
I'm not advocating that the ASF has to be part of the process, that's
something for the OSGi Alliance to decide.  However, if the ASF committers
can't be part of it, I don't how an implementation of a design in progress
can be done correctly inside an ASF project.



>
> Regards,
> Neil
>
> > On 18 Jan 2017, at 10:41, Guillaume Nodet  wrote:
> >
> > I'm a bit concerned by some subprojects in our communities.
> >
> > The ASF is supposed to be "community over code", so the very basic thing
> > for a project is that people can get involved.
> >
> > However, I see more and more code developped as a reference
> implementation
> > of a spec which is not publicly available, because it's still being
> > developed at the OSGi Alliance.  I find that very disturbing because
> > there's no way the community can get involved unless they are OSGi
> Alliance
> > members, and that's clearly not acceptable imho.
> >
> > Thoughts ?
> > Guillaume Nodet
>
>


-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Implementation of unreleased spec and community

[Felix Meschberger]

Hi all

And we should also mention that quite a number of active community members 
actually working on those things are members (or employees of members) of the 
OSGi alliance and as such open to feedback received from the communities on the 
evolution of the specifications.

As such, I think it is even positive for both the communities and the OSGi 
alliance to have Apache projects implement reference implementations.

Maybe we could do a better job in communicating that fact ?

Regards
Felix

> Am 18.01.2017 um 11:59 schrieb David Bosschaert :
> 
> Hi Guillaume,
> 
> First of all, the OSGi Alliance is a very open standards development
> organization. Any organisation can join. RFPs and RFCs are developed in the
> open, specs are available for free and are free to be implemented by anyone.
> 
> There is also an open feedback channel available where everyone can post
> feedback, described at https://github.com/osgi/design
> 
> OSGi works very hard in defining specs that are portable and can be
> implemented without the need to pay for any licenses or anything of that
> sort.
> 
> History has shown that spec implementations are really quite portable.
> Implementation bundles can be mixed from different sources and everything
> just works as long as you use the specced APIs.
> 
> Every new spec that is being worked on in OSGi needs, besides the RFP/RFC
> and spec chapter, a Reference Implementation and a Conformance Testsuite.
> Over the past 10 years or so, Reference Implementations have primarily been
> implemented in open source. This has the benefit that everyone can see what
> the implementation is going to be and also it allows everyone to provide
> feedback and participate in the implementation. Apache committers have free
> access to the relevant CTs as well.
> 
> I think this is all goodness. Or would you rather see that Reference
> Implementations are implemented in private?
> 
> Best regards,
> 
> David
> 
> 
> On 18 January 2017 at 10:41, Guillaume Nodet  wrote:
> 
>> I'm a bit concerned by some subprojects in our communities.
>> 
>> The ASF is supposed to be "community over code", so the very basic thing
>> for a project is that people can get involved.
>> 
>> However, I see more and more code developped as a reference implementation
>> of a spec which is not publicly available, because it's still being
>> developed at the OSGi Alliance.  I find that very disturbing because
>> there's no way the community can get involved unless they are OSGi Alliance
>> members, and that's clearly not acceptable imho.
>> 
>> Thoughts ?
>> Guillaume Nodet
>> 

Re: Implementation of unreleased spec and community

[David Bosschaert]

Hi Guillaume,

First of all, the OSGi Alliance is a very open standards development
organization. Any organisation can join. RFPs and RFCs are developed in the
open, specs are available for free and are free to be implemented by anyone.

There is also an open feedback channel available where everyone can post
feedback, described at https://github.com/osgi/design

OSGi works very hard in defining specs that are portable and can be
implemented without the need to pay for any licenses or anything of that
sort.

History has shown that spec implementations are really quite portable.
Implementation bundles can be mixed from different sources and everything
just works as long as you use the specced APIs.

Every new spec that is being worked on in OSGi needs, besides the RFP/RFC
and spec chapter, a Reference Implementation and a Conformance Testsuite.
Over the past 10 years or so, Reference Implementations have primarily been
implemented in open source. This has the benefit that everyone can see what
the implementation is going to be and also it allows everyone to provide
feedback and participate in the implementation. Apache committers have free
access to the relevant CTs as well.

I think this is all goodness. Or would you rather see that Reference
Implementations are implemented in private?

Best regards,

David


On 18 January 2017 at 10:41, Guillaume Nodet  wrote:

> I'm a bit concerned by some subprojects in our communities.
>
> The ASF is supposed to be "community over code", so the very basic thing
> for a project is that people can get involved.
>
> However, I see more and more code developped as a reference implementation
> of a spec which is not publicly available, because it's still being
> developed at the OSGi Alliance.  I find that very disturbing because
> there's no way the community can get involved unless they are OSGi Alliance
> members, and that's clearly not acceptable imho.
>
> Thoughts ?
> Guillaume Nodet
>

Re: Implementation of unreleased spec and community

[Neil Bartlett]

Guillaume,

All OSGi specifications in progress are publicly visible, so in what sense are 
Apache community members unable to be involved in the development of the RIs?

Regards,
Neil

> On 18 Jan 2017, at 10:41, Guillaume Nodet  wrote:
> 
> I'm a bit concerned by some subprojects in our communities.
> 
> The ASF is supposed to be "community over code", so the very basic thing
> for a project is that people can get involved.
> 
> However, I see more and more code developped as a reference implementation
> of a spec which is not publicly available, because it's still being
> developed at the OSGi Alliance.  I find that very disturbing because
> there's no way the community can get involved unless they are OSGi Alliance
> members, and that's clearly not acceptable imho.
> 
> Thoughts ?
> Guillaume Nodet