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 <gno...@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 <njbartl...@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 <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 <gno...@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: gno...@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

Reply via email to