2017-01-18 20:23 GMT+01:00 Richard S. Hall <he...@ungoverned.org>: > 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 <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
