[Jumping in late...] Stefan Hepper wrote: > Sorry for being late in this discussion but I just returned today from > my vacation. > > Let me first summarize some facts here: > - the JCP process requires that the company of the spec lead provides a > RI with the spec, for JSR 286 IBM needs to provide this RI
Correct but not really a concern for the Pluto community as such. > - IBM has contracted the University of Jena in order to provide the RI > and TCK. The goal was from the beginning to develop the RI at Apache > together with the pluto community. It would have been good form to ask the whole portals community whether it was interested in helping in the 2.0 RI. All community members have an equal say in this matter and it's not IBM to decide. > - what we are currently talking about is a prototype covering only the > coordination features of the early draft 1, not a complete implementation > - Apache has a seat in the JCP executive board and if Apache does not > like the current JCP process because it is too closed it should work in > the JCP EC to change the current process Apache has been a major force in pushing for JCP 2.6 which explicitely allows open style working groups (section 2.1.1 of the JCP 2.6). The actual choice of working style is defined by the JSR chair. > - for JSR 286 the pluto community has much more seats than anyone else, > every other company has only one seat > - the JSR 286 EG, incl. the pluto committers, voted for having a closed > discussion until we have the first early public draft in order to keep > the discussion in the EG focused and effective > - the JSR 286 EG decided to publish at least two early drafts in order > to give everyone the opportunity for comments and feedback, so I don't > think things are done in the close > Things may not have been done as in the close as JSR 186 but they are still far from a transparent process which you, as chair, could have chosen for this JSR. Given that choice, you need to accept that it does not mesh exactly with the way an Apache community works and that your RI may not be accepted as part of the Pluto project. > When founding the pluto project my intention was that it will provide > always the most current reference implementation, not just the V 1.0. > This is also stated in the charter of pluto. Thus I would like to see > V2.0 also be part of the pluto project. > In a stricly legal sense, I don't think Pluto can be the RI since the RI is under the responsibility of the spec chair. All it can be is a spec compliant container that is the basis for the JSR RI. > As said, what the Uni Jena did was just a prototype that they now want > to discuss with the pluto community. I don't see why it should be > something bad to first create a prototype in order to prove if some > design works or not. Note that they used the most current 1.1 driver > when starting this prototype work. > Maybe we can set up a wiki for this and they can post the design docs > and code there? > > To me it doesn't make sense to go to the incubator with the prototype. > Why can't the V2.0 development not be done under the pluto umbrella? > If Apache really requires us to go to the incubator I would rather do > this with a complete implementation and not a half-baked prototype. But > is this really what you guys want, getting a complete code drop? > What I would propose as steps forwards would be this: - make sure everybody here wants to implement JSR 286 in a next version of Pluto (Given the number of committers on the JSR, I guess it's going to be yes) - set up a sandbox area in the pluto repository so that all people interested can start working on prototyping some parts of the spec. Jena work can be one of these prototypes, there may be other competing designs by other committers. These designs may explore other features that may or may not end up in the JSR 286 spec. - once a consensus is built around a specific design (or a vote among competing designs), chose that design as a basis for Pluto 2.0. I don't see any value in getting through the incubator as long as everybody understands the licencing and operating implications, namely: - Ulrich needs to have the legal rghts to commit the code (cf the ICLA he signed) - once committed, this code is controlled by the ASF Portals processes, in particular code changes can be vetoed for technical reasons by any committer and *must* be reversed while the issue is being discussed and addressed by the community. All in all, the goal for me is to have Pluto 2.0 implementation that is the result of a collaborative process by all participants in the community and that can be supported by that community. Any indication that most of the community has no familiarity with the actual code (as happened in Pluto 1.0 and WSRP4J) would probably trigger a negative vote fom me on a release vote. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/
