Re: Implementation of unreleased spec and community

2017-01-20 Thread Guillaume Nodet
No, not at all, and I hope my actions are not taken against any one either. I had to mention you explicitly in order to make things more clear, sorry about that. Though I really do want to make sure the process more straight and make sure it's done fairly and by the rules. 2017-01-20 14:20 GMT+01:

Re: Implementation of unreleased spec and community

2017-01-20 Thread Guillaume Nodet
2017-01-20 14:49 GMT+01:00 Richard S. Hall : > On 1/20/17 05:42 , Guillaume Nodet wrote: > >> 2017-01-20 11:26 GMT+01:00 Neil Bartlett : >> >> On 20 Jan 2017, at 10:12, Guillaume Nodet wrote: 2017-01-20 10:58 GMT+01:00 Guillaume Nodet >>> >>> gno...@apache.org>>: >>> > 2017-01-

Re: Implementation of unreleased spec and community

2017-01-20 Thread Richard S. Hall
On 1/20/17 05:42 , Guillaume Nodet wrote: 2017-01-20 11:26 GMT+01:00 Neil Bartlett : On 20 Jan 2017, at 10:12, Guillaume Nodet wrote: 2017-01-20 10:58 GMT+01:00 Guillaume Nodet gno...@apache.org>>: 2017-01-19 19:36 GMT+01:00 Timothy Ward : At this point I’d also like to re-affirm that th

Re: Implementation of unreleased spec and community

2017-01-20 Thread Raymond Auge
Apparently I've severely offended you Guillaume. If so I sincerely apologize. That was never my intention. Sincerely, - Ray On Jan 20, 2017 5:42 AM, "Guillaume Nodet" wrote: 2017-01-20 11:26 GMT+01:00 Neil Bartlett : > > > On 20 Jan 2017, at 10:12, Guillaume Nodet wrote: > > > > 2017-01-20 10

Re: Implementation of unreleased spec and community

2017-01-20 Thread Guillaume Nodet
2017-01-20 11:26 GMT+01:00 Neil Bartlett : > > > On 20 Jan 2017, at 10:12, Guillaume Nodet wrote: > > > > 2017-01-20 10:58 GMT+01:00 Guillaume Nodet gno...@apache.org>>: > > > >> > >> > >> 2017-01-19 19:36 GMT+01:00 Timothy Ward : > >> > >>> At this point I’d also like to re-affirm that the OSGi

Re: Implementation of unreleased spec and community

2017-01-20 Thread Neil Bartlett
> On 20 Jan 2017, at 10:12, Guillaume Nodet wrote: > > 2017-01-20 10:58 GMT+01:00 Guillaume Nodet >: > >> >> >> 2017-01-19 19:36 GMT+01:00 Timothy Ward : >> >>> At this point I’d also like to re-affirm that the OSGi RFC documents are >>> public, and that there is a

Re: Implementation of unreleased spec and community

2017-01-20 Thread Christian Schneider
I agree that if someone works on a spec at OSGi alliance and on the impl code at Apache then he will have an advantage over someone who can only work on the code at Apache. This is a situation is not good. The question though is what can we really do to improve this. I think it is not possible

Re: Implementation of unreleased spec and community

2017-01-20 Thread Guillaume Nodet
2017-01-20 10:58 GMT+01:00 Guillaume Nodet : > > > 2017-01-19 19:36 GMT+01:00 Timothy Ward : > >> At this point I’d also like to re-affirm that the OSGi RFC documents are >> public, and that there is a public feedback mechanism for RFC bugs. As the >> holder of the pen for Transaction Control, the

Re: Implementation of unreleased spec and community

2017-01-20 Thread Guillaume Nodet
2017-01-19 19:36 GMT+01:00 Timothy Ward : > At this point I’d also like to re-affirm that the OSGi RFC documents are > public, and that there is a public feedback mechanism for RFC bugs. As the > holder of the pen for Transaction Control, the JAX-RS whiteboard, and the > JPA service updates I can

Re: Implementation of unreleased spec and community

2017-01-19 Thread Carsten Ziegeler
Thanks Guillaume for bringing this up and thanks everyone for the orderly discussions. I think it's important that someone brings up his concerns, that we value this and we can discuss about it. Looking at the various responses in this thread I have the feeling that all arguments are on the table.

Re: Implementation of unreleased spec and community

2017-01-19 Thread Timothy Ward
At this point I’d also like to re-affirm that the OSGi RFC documents are public, and that there is a public feedback mechanism for RFC bugs. As the holder of the pen for Transaction Control, the JAX-RS whiteboard, and the JPA service updates I can truthfully say that community discussion and fee

Re: Implementation of unreleased spec and community

2017-01-19 Thread David Leangen
>> 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. >> >> > This is factually incorrect at least for the Converter implementation at > Feli

Re: Implementation of unreleased spec and community

2017-01-19 Thread David Bosschaert
Hi Guillaume On 18 January 2017 at 23:03, Guillaume Nodet wrote: > 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. > > This is factually in

Re: Implementation of unreleased spec and community

2017-01-18 Thread Richard S. Hall
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

Re: Implementation of unreleased spec and community

2017-01-18 Thread Guillaume Nodet
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 w

Re: Implementation of unreleased spec and community

2017-01-18 Thread Richard S. Hall
On 1/18/17 15:28 , Guillaume Nodet wrote: 2017-01-18 20:23 GMT+01:00 Richard S. Hall : 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 o

Re: Implementation of unreleased spec and community

2017-01-18 Thread Guillaume Nodet
2017-01-18 20:23 GMT+01:00 Richard S. Hall : > 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

Re: Implementation of unreleased spec and community

2017-01-18 Thread Carsten Ziegeler
Richard S. Hall wrote > 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

Re: Implementation of unreleased spec and community

2017-01-18 Thread Richard S. Hall
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 a

Re: Implementation of unreleased spec and community

2017-01-18 Thread Raymond Auge
But this is exactly what is happening for many in-flight specifications and no one has ever complained! - tx-control - push streams - configurator - converter - etc. - Ray On Wed, Jan 18, 2017 at 2:06 PM, Guillaume Nodet wrote: > Let's take a clearer example, as I have a feeling I'm still not

Re: Implementation of unreleased spec and community

2017-01-18 Thread Guillaume Nodet
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

Re: Implementation of unreleased spec and community

2017-01-18 Thread Richard S. Hall
On 1/18/17 08:55 , Guillaume Nodet wrote: 2017-01-18 14:29 GMT+01:00 Richard S. Hall : On 1/18/17 08:22 , Guillaume Nodet wrote: 2017-01-18 13:53 GMT+01:00 Carsten Ziegeler : Whoever is doing the RI does it somewhere else and might do a code contribution or not. Yes, that definitely wou

Re: Implementation of unreleased spec and community

2017-01-18 Thread Christian Schneider
To a degree it also applies to any other spec but it is only visible when the spec is changing a lot. As we basically take the jax rs spec as given and static in this project there is not much pain in being not in the loop. For the jax-rs-whiteboard spec it is different as it is more of a movin

Re: Implementation of unreleased spec and community

2017-01-18 Thread Neil Bartlett
> On 18 Jan 2017, at 12:36, Guillaume Nodet 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 “JA

Re: Implementation of unreleased spec and community

2017-01-18 Thread Carsten Ziegeler
Ok, assuming that the OSGi Alliance is not changing its model of working, what do you propose to do? Carsten Guillaume Nodet wrote > It seems either I have a hard time explaining myself, or you're all blind. > I'll suppose the first one, so I'll try again. > > Let's say someone comes to aries or

Re: Implementation of unreleased spec and community

2017-01-18 Thread Guillaume Nodet
It seems either I have a hard time explaining myself, or you're all blind. I'll suppose the first one, so I'll try again. Let's say someone comes to aries or felix saying: "i'd like to work on a RI for the xxx rfc". At this point, that's fine if the RFC is kinda frozen. Let's imagine it's not, an

Re: Implementation of unreleased spec and community

2017-01-18 Thread Carsten Ziegeler
Guillaume Nodet wrote > >> There is no difference? Really? Claiming the current approach is not >> optimal from a community perspective is certainly not unreasonable, but >> saying that the community doesn't benefit at all from having draft >> implementations being worked on at Apache seems like a

Re: Implementation of unreleased spec and community

2017-01-18 Thread Guillaume Nodet
2017-01-18 14:29 GMT+01:00 Richard S. Hall : > On 1/18/17 08:22 , Guillaume Nodet wrote: > >> 2017-01-18 13:53 GMT+01:00 Carsten Ziegeler : >> >> Whoever is doing the RI >>> does it somewhere else and might do a code contribution or not. >>> >> >> Yes, that definitely would avoid the problem. >> A

Re: Implementation of unreleased spec and community

2017-01-18 Thread Guillaume Nodet
2017-01-18 11:59 GMT+01:00 David Bosschaert : > 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. > >

Re: Implementation of unreleased spec and community

2017-01-18 Thread Richard S. Hall
On 1/18/17 08:22 , Guillaume Nodet wrote: 2017-01-18 13:53 GMT+01:00 Carsten Ziegeler : Whoever is doing the RI does it somewhere else and might do a code contribution or not. Yes, that definitely would avoid the problem. And I don't think it changes anything from the contributor point of vie

Re: Implementation of unreleased spec and community

2017-01-18 Thread Guillaume Nodet
2017-01-18 13:53 GMT+01:00 Carsten Ziegeler : > Guillaume Nodet wrote > > > > Again, I'm talking about using Apache to develop the will-be reference > > implementation of the being-designed spec. When the rfc is undergoing > > changes, the RI, as you say, is an experimental project to make sure

Re: Implementation of unreleased spec and community

2017-01-18 Thread Carsten Ziegeler
Guillaume Nodet wrote > > Again, I'm talking about using Apache to develop the will-be reference > implementation of the being-designed spec. When the rfc is undergoing > changes, the RI, as you say, is an experimental project to make sure the > RFC properly address all problems and can be turne

Re: Implementation of unreleased spec and community

2017-01-18 Thread Bram Pouwelse
> 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 someth

Re: Implementation of unreleased spec and community

2017-01-18 Thread Guillaume Nodet
RFC-217 sorry https://github.com/osgi/design/tree/master/rfcs/rfc0217 2017-01-18 13:36 GMT+01:00 Guillaume Nodet : > 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:

Re: Implementation of unreleased spec and community

2017-01-18 Thread Guillaume Nodet
2017-01-18 13:22 GMT+01:00 Neil Bartlett : > Guillaume, you seem to be working from out of date information. All RFPs > and RFCs are publicly available, including those that are still being > developed. They are here: https://github.com/osgi/design/. This has been > the case for at least four year

Re: Implementation of unreleased spec and community

2017-01-18 Thread Guillaume Nodet
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 : > Christian, your example of JAX-RS Whiteboard is fascinating, because > JAX-RS was designed by the E

Re: Implementation of unreleased spec and community

2017-01-18 Thread Neil Bartlett
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 specific

Re: Implementation of unreleased spec and community

2017-01-18 Thread Neil Bartlett
Guillaume, you seem to be working from out of date information. All RFPs and RFCs are publicly available, including those that are still being developed. They are here: https://github.com/osgi/design/. This has been the case for at least four years now. Given this, I don’t see any impediment to

Re: Implementation of unreleased spec and community

2017-01-18 Thread Christian Schneider
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

Re: Implementation of unreleased spec and community

2017-01-18 Thread Guillaume Nodet
2017-01-18 11:46 GMT+01:00 Neil Bartlett : > Guillaume, > > All OSGi specifications in progress are publicly visible, so in what sense > are Apache community members unable to be involved in the development of > the RIs? > I'm not talking about developing an implementation of a publicly released

Re: Implementation of unreleased spec and community

2017-01-18 Thread Felix Meschberger
Hi all And we should also mention that quite a number of active community members actually working on those things are members (or employees of members) of the OSGi alliance and as such open to feedback received from the communities on the evolution of the specifications. As such, I think it i

Re: Implementation of unreleased spec and community

2017-01-18 Thread David Bosschaert
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 everyo

Re: Implementation of unreleased spec and community

2017-01-18 Thread Neil Bartlett
Guillaume, All OSGi specifications in progress are publicly visible, so in what sense are Apache community members unable to be involved in the development of the RIs? Regards, Neil > On 18 Jan 2017, at 10:41, Guillaume Nodet wrote: > > I'm a bit concerned by some subprojects in our communiti