On 1/18/17 18:03 , Guillaume Nodet wrote:
The problem is when the "what" is being prototyped in an Apache project,
not the "how".  The "how" can be done by any committer, but if the "what"
is still being discussed, you really have no saying over the "how" yet.
Basically, no one will ever question an implementation decision until the
spec work is finished.  Which means that no one will question anything
until the implementation (if that's the RI) is finished too, at which
point, there's nothing to say anymore, unless you want to rewrite the whole
thing.
That's definitely not community work.

So you're right, it's temporary until the spec work is published, at which
point the implementation is also finished and it's too late.  Especially if
the RI will have to be released roughly at the same time than the spec.

Ray has listed a number of things that have been implemented during the
past few months.  All of them have been written by a single committer who
also happen to be the one modifying the spec document.  So I don't see any
real ground for invoking a community involvement, when there's definitely
none.  If what you think about community work is limited to reading
existing code and eventually providing a few comments, those things can
easily be done anywhere.

I disagree that it is not possible to have say over the "how" if you don't have any say over the "what" while it is being developed, unless there is an active effort by the people involved to not answer questions and/or hide what they are doing.

Is it more work when you don't have a complete spec? Sure, because it involves actually engaging others to get answers or combing through code to figure it out (like you have to do in most open source projects).

I'm not sure this discussion is bearing any fruit. Is there something you'd like to propose? If I were to agree that this is an issue, then the only thing I can see to resolve it is banning all work on provisional specs, which definitely doesn't seem like a good course of action.

-> richard





Guillaume

2017-01-18 21:52 GMT+01:00 Richard S. Hall <he...@ungoverned.org>:

On 1/18/17 15:28 , Guillaume Nodet wrote:

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.

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




Reply via email to