> 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 <gno...@apache.org> wrote: > RFC-217 sorry > https://github.com/osgi/design/tree/master/rfcs/rfc0217 > > > > 2017-01-18 13:36 GMT+01:00 Guillaume Nodet <gno...@apache.org>: > > > 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 <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/ > > > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ >
