felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Implementation of unreleased spec and community
Date Wed, 18 Jan 2017 20:52:39 GMT
On 1/18/17 15:28 , Guillaume Nodet wrote:
> 2017-01-18 20:23 GMT+01:00 Richard S. Hall <heavy@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.

They are equal in the eyes of Apache, but that doesn't mean that they 
are equal with respects to their external memberships. You appear to 
want to go down a rat hole that has no escape. No matter what, 
committers who are members of standards bodies are "not equal" to 
committers who are not in the eyes of the standards bodies. This is true 
with regardless of whether the spec is released or not, so I'm still not 
sure of your point.

People in the standards body have more say in how things will go in what 
will ultimately be implemented, but they do not have any more say in how 
it will be implemented in any given Apache project. They just get a leg 
up on implementing it before the spec is completely public, but that 
doesn't make their kung-fu more equal than anyone else and they will 
still be accountable for any technical discussions/decisions/debates 
that ensue as a result.

>
>
>> 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?

But you seem to be implying that they aren't obeying the rules because 
they have access to unreleased specs which doesn't really hold water 
with me.

The only thing that you are saying that is true is that people will have 
some difficulty contributing if they don't have the spec to read. Sure, 
this is probably the case, but this certainly doesn't prevent people 
from commenting and/or contributing to it. Most open source work doesn't 
have a spec for people to work against and they still generally jump in 
and contribute. And, as I said before, it is only temporary.

-> richard

>
>
>>
>> -> richard
>>
>>
>>
>>>
>>> 2017-01-18 15:29 GMT+01:00 Neil Bartlett <njbartlett@gmail.com>:
>>>
>>> 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/
>>>>>
>>>>
>


Mime
View raw message