Raphaël Luta wrote:
[Jumping in late...]
Stefan Hepper wrote:
- 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.
As said I always assumed that was the goal of the pluto project as
stated in the first sentence of the pluto web site:
" Pluto is the Reference Implementation of the Java Portlet
Specfication."
Maybe I just assumed too much and thus I apologize for not sending an
official request to the mailing list.
- 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.
- 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.
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.
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.
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.
Stefan
|
