2017-01-19 19:36 GMT+01:00 Timothy Ward <timothyjw...@apache.org>: > 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 > feedback has influenced the direction of those RFCs/specifications, not > just the converter. > > As David says below, you can gain increased control over the direction of > things anywhere by becoming a member/committer/employee. Committers in > Apache Aries have ample opportunity to review and discuss the many > implementations built there, just as they do in Felix. This right applies > both before and after the release of the specification. What Apache > Committers can’t do is make changes to an OSGi RFC/spec, for that they need > to lobby an OSGi member.
I have no problems with the above. > This is exactly the same for a committer in Eclipse, on Github, or in a > private company, so it leaves Apache committers just as equal as everyone > else. I don't care about how Eclipse or Github project are operated. We're talking about Apache projects and there are rules. One of them is that committers are considered equal. > The main difference here is that there are a lot of OSGi members who > believe in Apache, and therefore contribute as committers. Are we really > saying that those committers should be disallowed because they are OSGi > members and therefore have “more power”? > Not disallowed, but yes, they should not do something within the ASF that other committers who are not OSGi members can't do. So to be clear: if any committer want to work on an implementation of an RFC or spec from the OSGi Alliance, that's fine, whether they are OSGi members or not. If an OSGi member want to work on spec design within the ASF bounds, I think that's not fine. In particular, if someone propose to develop some code to implement an RFC when the API from the developped and later introduced back into the RFC document, I think that's definitely spec work, and should not be done within the RFC. To be crystal clear, I have a problem with Ray willing to bring code for implementing rfc-193 in Aries, when the code that he wants to bring contains lots of things that are not reflected in the RFC document and the opposite. Ray and David explained that the RFC document will be updated in the coming weeks to reflect those changes. This is definitely spec work, and that's fine, but I don't think it should happen at Apache. Again, it's a timing problem wrt to changes in the document and changes in the code : if the code is changes first by the spec lead, and later validated on during OSGi meetings and later integrated into the spec document and made public, I definitely see that as spec work, not as building an implementation, and imho this is unfair to other committers because it does not follow the ASF rules. It's certainly open source, but not the Apache way. > > Finally, there are a lot of projects and/or components in Open Source > (including Apache) that are written by a single committer, typically the > person with the itch to scratch. Only If that committer tries to prevent > discussion about, or changes to, that code is there a problem for the > community. To my knowledge this does not apply to any of the components in > Apache Aries or Apache Felix. > A piece of code being developed by a single person is definitely not a good thing within the ASF. Again, the ASF operates with community over code mantra and requires diversity within a project to avoid dictatorship and to ensure that the code development is overseen and can be maintained if one people is going away. Having some code being developed by a single person certainly does not help. The fact that it has almost always been the case for a bunch of subprojects in Felix or Aries does not mean it's healthy nor good. But this is slightly mitigated by the fact that over time, people tend to jump and fix things when they need. Obviously, if that person would try to prevent discussion or code changes, that would be definitely a critical problem, but I haven't seen such a behavior. > > Best Regards, > > Tim Ward > > > On 19 Jan 2017, at 17:32, David Leangen <o...@leangen.net> 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 incorrect at least for the Converter implementation at > >> Felix. Just look at the commit history for commits done on behalf of > >> community members and also check the mailing list for discussions that > >> definitely provided great feedback on the work done. > > > > I have been doing a very tiny bit of work on the Converter as a double > outsider (non committer in Felix, and non OSGi member). > > > > I completely rely on others to accept my contributions and suggestions, > making me a kind of second class citizen. It does work, but I need to > either (i) become a first class citizen either by merit or paying fees, > depending on the organisation, or (ii) accept my dependence on the goodwill > of others. Currently I have a de facto sponsor who has been very attentive > to my questions and contributions, so (ii) is working out well enough. If > it didn’t work out, could always fall back on option (i). > > > > So I can understand the frustrations and agree that there is a bit of a > grey area, but at the same time I understand that in the end I have the > same opportunities as everybody else. In this case, I am not willing/able > to “pay the price” for full citizenship, so I don’t feel I have the right > to complain. > > > > > > Just my 2¥. > > > > Cheers, > > =David > > > > > > -- ------------------------ Guillaume Nodet
