Stefan Hepper wrote: > Raphaël Luta wrote: >>Stefan Hepper wrote: >>> <snip> >>>- 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. >> > That is not completely true. Every EG member needs to approve working in > such an open style. E.g. I asked the EG if we want to have a public > mailing list or a closed one and some EG members preferred a closed one. >
My point was that JCP does not impose any closed process anymore, it's a choice made for JSR 286 by the Expert Group led by the spec lead. I believe it's disingenuous to hide behind a non-exitent JCP constraint to excuse the close process. >>>- 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. >> > As said above you need to have an agreement in the EG about the working > style. Agreed that the JSR 286 EG operates in a more closed manner than > an Apache community. > I would find it sad, but would accept it if the pluto community decides > to not host the bases for the RI for JSR 286 and just provide an > implementation of JSR 286. > I'm not sure what differences you make between "an implementation of JSR 286" and the "RI for JSR 286". To me, granting RI status on an implementation of a JSR spec is the sole responsibility of the spec lead. Since most people in pluto want to implement JSR 286, Pluto should aim to be a powerful, spec compliant container. What I would not like to see is some community produced feature freezed out of Pluto because of a will to keep a "RI purity". >>>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. >> > I think it can be more as a specific drop of pluto could be submitted as > RI like done in JSR 168. But I see your point and think we need to > re-visit the current pluto agenda. > I agree that if the compliance is good enough, the RI could be a simple snapshot of Pluto submitted by IBM, but it would not be Apache Pluto, simply a derivative work. >>>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? >> >> <snip> > > I would have been nice if you could have made yesterday's call. Please > take a look at David's summary mail. I think it is not far off from your > proposal. > I think we're on the same line on how to proceed going forward. My only adjustment would be not to name the initial branch "pluto-2.0" but something like "jsr286-prototype-1". This will allow the possibility of having a "jsr286-proto2" if needed and only when the work is more fleshed out, promote one of the prototype branches to an "official" pluto 2.0 branch. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/
