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
- 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.
- 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
- 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
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.
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?
Stefan
David H. DeWolf wrote:
Craig Doremus wrote:
1I understand their are some historical reasons to proceed
cautiously, so please have the Portals PMC vote on this matter as
soon as possible.
Craig, here is what I think the key point of this discussion is:
> Santiago Gala wrote:
>>
>> Now, if the components of such team have the whole communications on
>> pluto-dev, and they send patches (except for Ulrich, which is a
>> committer) that get integrated until they earn committership, the
>> process would not need to pass through the incubator.
>>
The only way to accomplish that is for the implementers from the
university to start to join our conversations on THIS LIST. I think
we're all very open to their participation are willing to work through
whatever barriers exist as long as it's done the Apache Way.
Because of that, I feel as though we should wait to hold any sort of
vote or make a decision. Let's give them a chance to collaborate with
us since that's exactly what we're asking for.
My only suggestion is that keeping track of the Jena contributions is
better done in Jira rather than on pluto-dev. Nevertheless, I am
willing to abide by what ever the PMC decides.
I think that the references to pluto-dev are aimed at ensuring that
DISCUSSIONS and DECISION MAKING for 2.0 involve the entire portals
team. Jira Issues alone will not promote this.
If I understand what everyone else is saying correctly, patches being
contributed through JIRA will be ok as long as they:
1) Are small iterative steps (typical patch sizes) and not a disguised
code dump.
2) Are discussed on the list prior to implementation (in the case of
brand new features).
David
