felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram Pouwelse <b...@pouwelse.com>
Subject Re: Implementation of unreleased spec and community
Date Wed, 18 Jan 2017 12:47:01 GMT
> 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 <gnodet@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 <gnodet@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 <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/
> >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message