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 <gno...@apache.org> 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 <njbartl...@gmail.com>: > > > > > > 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/ > > > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
