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