felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Implementation of unreleased spec and community
Date Wed, 18 Jan 2017 14:50:14 GMT
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 <gnodet@apache.org> 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 <njbartlett@gmail.com>:
>>
>>> 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 <chris@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 <gnodet@apache.org>
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: gnodet@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/


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

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


Mime
View raw message