You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by CD...@hannaford.com on 2006/08/24 21:03:07 UTC
Creating a Pluto 2.0 branch
IBM has contracted with a group at the University of Jena in Germany to
help create the reference implementation of JSR-286 to be hosted at
Apache. David and I have been in contact with this group, which is headed
by Torsten Dettborn, a member of the JSR-286 Expert Group. Torsten's group
has done some work on the JSR-286 RI based on Pluto 1.1 that they want to
contribute to our repository.
Unless anyone objects, I would like to create a Pluto 2.0 branch in SVN to
house the JSR-286 Reference Implementation code. The starting point for
this branch will be the Pluto 1.1 code now in our SVN trunk.
This is a great chance for the community to contribute to the JSR-286 RI
and get an early look at an implementation of the developing JSR-286 spec.
/Craig
Re: Creating a Pluto 2.0 branch
Posted by Santiago Gala <sa...@gmail.com>.
On 8/24/06, CDoremus@hannaford.com <CD...@hannaford.com> wrote:
> They are contributing code that builds on our current code base. I do not
> see why it has to go through the incubation process. Like Tomcat, which revs
> up a version for a new servlet/JSP spec, we are creating a new version that
> corresponds to the new portlet spec.
> /Craig
The big difference is that "they" in the tomcat case, is apache
committers. Here, we don't know who "they" is, and "they" are working
in the close, without communitty vetting of the code, and ignoring the
apache rules absolutely
Re: Creating a Pluto 2.0 branch
Posted by Raphaël Luta <ra...@apache.org>.
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 - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
Re: Creating a Pluto 2.0 branch
Posted by Stefan Hepper <st...@apache.org>.
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
Re: Creating a Pluto 2.0 branch
Posted by Raphaël Luta <ra...@apache.org>.
[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 - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
Re: Creating a Pluto 2.0 branch
Posted by Stefan Hepper <st...@apache.org>.
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
>
>
Re: Creating a Pluto 2.0 branch
Posted by "David H. DeWolf" <dd...@apache.org>.
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
Re: Creating a Pluto 2.0 branch
Posted by Craig Doremus <cd...@apache.org>.
Santiago:
At the first Expert Group face-to-face meeting, JSR-286 spec lead Stefan
Hepper told us:
1. IBM was contracting with the Univ of Jena to help produce the JSR-286
Reference Implementation.
2. He wants Apache Pluto to host the RI code
3. He wants to base the JSR-286 RI on Apache Pluto 1.1
There are seven Apache Portals committers, including Stefan, who are
members of the Expert Group, so many of us should have known that this
was coming. Another constraint is the Java Community Process (JCP) rules
that state that EG information should not be disclosed before the are
formally released in document form. The first early draft was released a
couple of weeks ago, which is why this discussion is happening now.
Stefan has been away on vacation for a couple of weeks, so hopefully he
will chime in when he gets back.
A couple of weeks ago, Torsten Dettborn of the Univ of Jena contacted
David and I about beginning the process of incorporating their work into
Pluto's SVN repository. Torsten's command of English is limited, which
may be the reason he has not chimed in yet on this thread. I have
invited Carsten Zeigler to participate in talks with Torsten to
facilitate communication between Apache and the Jena group. Although
Ulrich Kuster is a Pluto committer, Torsten told me that he has not been
involved with them since Jan-Feb.
I for one am very happy that we have a paid group that can dedicate
their time to building Pluto 2.0. David and I, and I understand, the
rest of the Pluto contributors, are volunteers. That does not diminish
our commitment to the project, but we have to fit it in when we can. We
all want to contribute to Pluto 2.0, but it is good that we have the
Univ of Jena group to help move the project forward.
Please excuse my presumption that the Pluto 2.0 branch creation process
was not any different from what we did with the Pluto 1.0.2 and Pluto
1.1 branch. I understand their are some historical reasons to proceed
cautiously, so please have the Portals PMC vote on this matter as soon
as possible. 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.
TIA
/Craig
Santiago Gala wrote:
> No, my reason for the -1 is that "IBM has contracted with a group at
> the University of Jena in Germany to help create the reference
> implementation of JSR-286 to be hosted at Apache. ", as cdoremus put
> it. This means that the code result is a work for hire, and thus would
> need to go through corporate CLA, vetting, etc. in the incubator.
>
> OTOH, given the secrecy which has involved the whole JSR process (a
> committer of the portals project was the chair, but we actually got
> the first notice through the JCP website, etc.) I'm afraid we will be
> again in a world of obscure changes, which go straight against the
> Apache Community spirit, and is the kind of things that have been
> slowly killing this project in the last couple of years, from the
> community point of view.
>
> 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.
>
> This is not an opinion, I think this is hard policy in the ASF. Apache
> is about communities, not about code.
>
> I (this is an opinion) don't care a dime about Reference
> Implementations unless they are used and tested. This is the case now
> with pluto 1.0, but it was not the case when it got donated.
>
> I am afraid that we are facing a code dump that will take a lot of
> time to clean up. Those are my concerns.
>
> Regards
> Santiago
>
> On 8/25/06, Ralph Goers <Ra...@dslextreme.com> wrote:
>
>> Santiago Gala wrote:
>> > I'm -1 about the branch.
>> >
>> Is your reason for the -1 because you feel that the JSR 286 work should
>> happen on trunk (assuming it was Pluto committers doing the work)?
>> Wouldn't you need to create a branch for 1.1 before you could start
>> that?
>>
>> Ralph
>>
>
>
Re: Creating a Pluto 2.0 branch
Posted by Ulrich Küster <Ul...@uni-jena.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
> Torsten, Stefan, and Ulrich, would you all mind chiming in to this
> discussion? This is how I'd definitely like to see the work done. Is
> that a possibility or is there something holding the Univ of Jena and
> IBM from working in this way.
sorry for my late answer, I had been missing this discussion so far.
Concerning my person I have been leading the work on portals here in
Jena until this year's spring when Torsten joined the team. I always had
to divide my time between Pluto and other projects (and duties) thus my
ability to contribute to Pluto was naturally limited.
Torsten however is able to work nearly full time on Pluto, thus we
decided the project would benefit if he took over, so one person
(Torsten) could fully concentrate on Pluto while I in turn would take
care of the other projects in Jena (which is the reason why I haven't
been active on Pluto recently).
Torsten has since been working on a prototype for Pluto 2 and for what I
understood the only reason why this work could not be done at Apache are
limitations concerning the JCP process as outlined by Craig and Stefan
("Another constraint is the Java Community Process (JCP) rules that
state that EG information should not be disclosed before they are
formally released in document form"). By no means is there any attempt
by anyone here in Jena to "keep things in private", after all we are a
university group, not a company. :-)
It was always and still is planned to move the development to Apache as
soon as possible (that is as soon as JCP rules allow).
Frankly I'm thus quite surprised by the wariness and reserve expressed
by this discussion, especially since the Apache portals community is so
well represented in the expert group (while University Jena by the way -
like everybody else - has only one seat). I understand though that
"information policy" from the viewpoint of many pluto committers and
contributers has been somewhat unfortunate.
Anyway, for the benefit of Pluto I hope and I'm optimistic any remaining
issues will be resolved in the phone conference tomorrow.
Best regards,
Ulrich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: GnuPT 2.9.2
iD8DBQFE9DVl8VxeCU3I0jARAkzYAJ9oAIzuIeHWAdAKI5XEXx0+tO1ZhQCfTWRx
NHFAUjz/Uah66qrxm+HiIfo=
=KyvS
-----END PGP SIGNATURE-----
Re: Creating a Pluto 2.0 branch
Posted by David Sean Taylor <da...@bluesunrise.com>.
David H. DeWolf wrote:
>
> 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.
>
>
> Great! Thanks for clarifying Santiago. Now I think we know how this
> needs to be handled.
>
> Torsten, Stefan, and Ulrich, would you all mind chiming in to this
> discussion? This is how I'd definitely like to see the work done. Is
> that a possibility or is there something holding the Univ of Jena and
> IBM from working in this way.
>
> I really think that this type of collaboration would be beneficial to
> both the portlet development community as well as pluto community. What
> do you think? Can we take this approach? I have just become an
> independent contractor in order to focus more time on my open source and
> pluto development. I'm committed to helping evaluate and commit
> patches as well as participate in discussions.
>
> David
>
>
Key decisions have to be made in the public, on the list.
Everyone can participate, contributors, committers
But we still must do things the apache way, in the open on the list,
discuss, present proposals, vote.
Re: Creating a Pluto 2.0 branch
Posted by "David H. DeWolf" <dd...@apache.org>.
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.
Great! Thanks for clarifying Santiago. Now I think we know how this
needs to be handled.
Torsten, Stefan, and Ulrich, would you all mind chiming in to this
discussion? This is how I'd definitely like to see the work done. Is
that a possibility or is there something holding the Univ of Jena and
IBM from working in this way.
I really think that this type of collaboration would be beneficial to
both the portlet development community as well as pluto community. What
do you think? Can we take this approach? I have just become an
independent contractor in order to focus more time on my open source and
pluto development. I'm committed to helping evaluate and commit
patches as well as participate in discussions.
David
Re: Creating a Pluto 2.0 branch
Posted by Santiago Gala <sa...@gmail.com>.
No, my reason for the -1 is that "IBM has contracted with a group at
the University of Jena in Germany to help create the reference
implementation of JSR-286 to be hosted at Apache. ", as cdoremus put
it. This means that the code result is a work for hire, and thus would
need to go through corporate CLA, vetting, etc. in the incubator.
OTOH, given the secrecy which has involved the whole JSR process (a
committer of the portals project was the chair, but we actually got
the first notice through the JCP website, etc.) I'm afraid we will be
again in a world of obscure changes, which go straight against the
Apache Community spirit, and is the kind of things that have been
slowly killing this project in the last couple of years, from the
community point of view.
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.
This is not an opinion, I think this is hard policy in the ASF. Apache
is about communities, not about code.
I (this is an opinion) don't care a dime about Reference
Implementations unless they are used and tested. This is the case now
with pluto 1.0, but it was not the case when it got donated.
I am afraid that we are facing a code dump that will take a lot of
time to clean up. Those are my concerns.
Regards
Santiago
On 8/25/06, Ralph Goers <Ra...@dslextreme.com> wrote:
> Santiago Gala wrote:
> > I'm -1 about the branch.
> >
> Is your reason for the -1 because you feel that the JSR 286 work should
> happen on trunk (assuming it was Pluto committers doing the work)?
> Wouldn't you need to create a branch for 1.1 before you could start that?
>
> Ralph
>
Re: Creating a Pluto 2.0 branch
Posted by Ralph Goers <Ra...@dslextreme.com>.
Santiago Gala wrote:
> I'm -1 about the branch.
>
Is your reason for the -1 because you feel that the JSR 286 work should
happen on trunk (assuming it was Pluto committers doing the work)?
Wouldn't you need to create a branch for 1.1 before you could start that?
Ralph
Re: Creating a Pluto 2.0 branch
Posted by Santiago Gala <sg...@apache.org>.
If the development process is not done in the apache community, the
code must go through the incubator.
small patches for bugfixes are exempt from this process, because there
are explicit disclaimers around this in JIRA, etc.
But here (and the original email expresses the intent very well), we
are not speaking about small patches, but about a code donation.
The code, if not developed in apache, should go through the incubator.
The way I see it, the development as a whole must go through the
incubator unless every single patch passes through JIRA anad is vetted
by the pluto community.
I'm -1 about the branch.
On 8/25/06, Carsten Ziegeler <cz...@apache.org> wrote:
> David H. DeWolf wrote:
> > Yup, we just need to make sure that we provide the protocol in order to
> > follow Apache ByLaws. We need the PMC to have the correct level of
> > oversight. I'm no expert on this so I'll rely on Carsten and others for
> > their assistance.
> >
> > Carsten, if we take the patch and incremental commit approach do you
> > think we still need to go through the incubator?
> Hmm, I'm really not sure - in general patches do not have to go through
> the incubator, so the question becomes "when is it a patch and when is
> it a code donation?" Adding something to jira does not necessarily mean
> that it is a patch.
> Now, I don't want to imply that this will/is happening here with pluto
> 2.0, I just want to express the possibilities: it is not that hard to
> split up a big code donation into a set of patches. Allowing this would
> mean bypassing the incubator.
>
> So, we should really make sure that these are "real patches" (whatever
> that means) :) Anyways, i think we should ask our PMC; if they approve
> it, I'm fine.
>
> > In a way I kind of
> > agree with Craig that this development is more like "enhancements" to an
> > existing codebase (after all, it's all on top of 1.1) as opposed to a
> > totally new project. At the same time, I want to make sure we follow
> > the right protocol.
> Yes, that's my pov as well.
>
> It would be great if the people "behind the patches" :) would make
> themselves heard on this list though.
>
> Carsten
>
> --
> Carsten Ziegeler - Open Source Group, S&N AG
> http://www.s-und-n.de
> http://www.osoco.org/weblogs/rael/
>
Re: Creating a Pluto 2.0 branch
Posted by "David H. DeWolf" <dd...@apache.org>.
+1
> It would be great if the people "behind the patches" :) would make
> themselves heard on this list though.
>
> Carsten
>
Re: Creating a Pluto 2.0 branch
Posted by Carsten Ziegeler <cz...@apache.org>.
David H. DeWolf wrote:
> Yup, we just need to make sure that we provide the protocol in order to
> follow Apache ByLaws. We need the PMC to have the correct level of
> oversight. I'm no expert on this so I'll rely on Carsten and others for
> their assistance.
>
> Carsten, if we take the patch and incremental commit approach do you
> think we still need to go through the incubator?
Hmm, I'm really not sure - in general patches do not have to go through
the incubator, so the question becomes "when is it a patch and when is
it a code donation?" Adding something to jira does not necessarily mean
that it is a patch.
Now, I don't want to imply that this will/is happening here with pluto
2.0, I just want to express the possibilities: it is not that hard to
split up a big code donation into a set of patches. Allowing this would
mean bypassing the incubator.
So, we should really make sure that these are "real patches" (whatever
that means) :) Anyways, i think we should ask our PMC; if they approve
it, I'm fine.
> In a way I kind of
> agree with Craig that this development is more like "enhancements" to an
> existing codebase (after all, it's all on top of 1.1) as opposed to a
> totally new project. At the same time, I want to make sure we follow
> the right protocol.
Yes, that's my pov as well.
It would be great if the people "behind the patches" :) would make
themselves heard on this list though.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Creating a Pluto 2.0 branch
Posted by "David H. DeWolf" <dd...@apache.org>.
Craig Doremus wrote:
> Torsten, who already subscribes to this list, appears to be cooperative.
> He wants to work with us and contribute code to our SVN repository with
> the help of current Pluto committers. He already has agreed to work on
> PLUTO-233 and PLUTO-232/249. two of the most important container-related
> Pluto 1.1 issues.
Great. I'm sure he is - didn't mean to imply that he won't be.
>
> I am suggesting that we create a Pluto 2.0 branch based on our current
> Pluto 1.1 trunk. I then suggest that we create a 2.0 version or branch
> in Jira. Torsten and his group can submit their code by creating issues
> in this Jira branch and attaching their files or patches to these
> issues. It will be up to the Pluto committers to add these contributions
> to SVN. In time, I hope that Torsten can earn the right to be a
> committer himself. Others will also be encouraged to contribute to the
> Pluto 2.0 branch.
Also, isn't one of his team members a committer (Ulrich)? I have no
problem with him committing the changes. At the same time, I don't mind
helping out.
>
> I am willing to go along with the group consensus, but I hope we can
> move the JSR-286 (Portlet 2.0) RI forward without any undue bureaucracy.
> /Craig
Yup, we just need to make sure that we provide the protocol in order to
follow Apache ByLaws. We need the PMC to have the correct level of
oversight. I'm no expert on this so I'll rely on Carsten and others for
their assistance.
Carsten, if we take the patch and incremental commit approach do you
think we still need to go through the incubator? In a way I kind of
agree with Craig that this development is more like "enhancements" to an
existing codebase (after all, it's all on top of 1.1) as opposed to a
totally new project. At the same time, I want to make sure we follow
the right protocol.
David
>
> David H. DeWolf wrote:
>
>> No matter if it goes through the incubator or not, I'd like to make
>> sure the pluto committers have an opportunity to review the code
>> before it's committed. I was originally under the impression that the
>> way this development was going to work was that instead of a code
>> "grant" or dump, incremental modifications would take place in a
>> branch - all starting from a clean 1.1 branch.
>>
>> If this is not the way it will work, we just need to iron out the
>> protocol - such as if the incubator is the right approach.
>>
>> In terms of our contact with Torsten, I personally have had any
>> discussions other than trying to connect with him. I think the ideal
>> would be for him (and others on his team) to join the pluto-dev list
>> and allow us to all contribute to the discussions. . .
>>
>> Just my 2 cents. . .
>>
>>
>> David
>>
>> CDoremus@hannaford.com wrote:
>>
>>>
>>> see below
>>> Carsten Ziegeler <cz...@apache.org> wrote on 08/24/2006 03:54:44 PM:
>>>
>>> > CDoremus@hannaford.com wrote:
>>> > > IBM has contracted with a group at the University of Jena in
>>> Germany to
>>> > > help create the reference implementation of JSR-286 to be hosted at
>>> > > Apache. David and I have been in contact with this group, which
>>> is headed
>>> > > by Torsten Dettborn, a member of the JSR-286 Expert Group.
>>> Torsten's group
>>> > > has done some work on the JSR-286 RI based on Pluto 1.1 that
>>> they want to
>>> > > contribute to our repository.
>>> > >
>>> > > Unless anyone objects, I would like to create a Pluto 2.0 branch
>>> in SVN to
>>> > > house the JSR-286 Reference Implementation code. The starting
>>> point for
>>> > > this branch will be the Pluto 1.1 code now in our SVN trunk.
>>> > >
>>> > > This is a great chance for the community to contribute to the
>>> JSR-286 RI
>>> > > and get an early look at an implementation of the developing
>>> JSR-286 spec.
>>> > I think every code donation must go through the incubator first,
>>> so we
>>> > should definitly first check with them.
>>> >
>>>
>>> They are contributing code that builds on our current code base. I do
>>> not see why it has to go through the incubation process. Like Tomcat,
>>> which revs up a version for a new servlet/JSP spec, we are creating a
>>> new version that corresponds to the new portlet spec.
>>> /Craig
>>>
>>>
>>> > Carsten
>>> > --
>>> > Carsten Ziegeler - Open Source Group, S&N AG
>>> > http://www.s-und-n.de
>>> > http://www.osoco.org/weblogs/rael/
>>
>>
>>
>
>
Re: Creating a Pluto 2.0 branch
Posted by Craig Doremus <cd...@apache.org>.
Torsten, who already subscribes to this list, appears to be cooperative.
He wants to work with us and contribute code to our SVN repository with
the help of current Pluto committers. He already has agreed to work on
PLUTO-233 and PLUTO-232/249. two of the most important container-related
Pluto 1.1 issues.
I am suggesting that we create a Pluto 2.0 branch based on our current
Pluto 1.1 trunk. I then suggest that we create a 2.0 version or branch
in Jira. Torsten and his group can submit their code by creating issues
in this Jira branch and attaching their files or patches to these
issues. It will be up to the Pluto committers to add these contributions
to SVN. In time, I hope that Torsten can earn the right to be a
committer himself. Others will also be encouraged to contribute to the
Pluto 2.0 branch.
I am willing to go along with the group consensus, but I hope we can
move the JSR-286 (Portlet 2.0) RI forward without any undue bureaucracy.
/Craig
David H. DeWolf wrote:
> No matter if it goes through the incubator or not, I'd like to make
> sure the pluto committers have an opportunity to review the code
> before it's committed. I was originally under the impression that the
> way this development was going to work was that instead of a code
> "grant" or dump, incremental modifications would take place in a
> branch - all starting from a clean 1.1 branch.
>
> If this is not the way it will work, we just need to iron out the
> protocol - such as if the incubator is the right approach.
>
> In terms of our contact with Torsten, I personally have had any
> discussions other than trying to connect with him. I think the ideal
> would be for him (and others on his team) to join the pluto-dev list
> and allow us to all contribute to the discussions. . .
>
> Just my 2 cents. . .
>
>
> David
>
> CDoremus@hannaford.com wrote:
>
>>
>> see below
>> Carsten Ziegeler <cz...@apache.org> wrote on 08/24/2006 03:54:44 PM:
>>
>> > CDoremus@hannaford.com wrote:
>> > > IBM has contracted with a group at the University of Jena in
>> Germany to
>> > > help create the reference implementation of JSR-286 to be hosted at
>> > > Apache. David and I have been in contact with this group, which
>> is headed
>> > > by Torsten Dettborn, a member of the JSR-286 Expert Group.
>> Torsten's group
>> > > has done some work on the JSR-286 RI based on Pluto 1.1 that
>> they want to
>> > > contribute to our repository.
>> > >
>> > > Unless anyone objects, I would like to create a Pluto 2.0 branch
>> in SVN to
>> > > house the JSR-286 Reference Implementation code. The starting
>> point for
>> > > this branch will be the Pluto 1.1 code now in our SVN trunk.
>> > >
>> > > This is a great chance for the community to contribute to the
>> JSR-286 RI
>> > > and get an early look at an implementation of the developing
>> JSR-286 spec.
>> > I think every code donation must go through the incubator first,
>> so we
>> > should definitly first check with them.
>> >
>>
>> They are contributing code that builds on our current code base. I do
>> not see why it has to go through the incubation process. Like Tomcat,
>> which revs up a version for a new servlet/JSP spec, we are creating a
>> new version that corresponds to the new portlet spec.
>> /Craig
>>
>>
>> > Carsten
>> > --
>> > Carsten Ziegeler - Open Source Group, S&N AG
>> > http://www.s-und-n.de
>> > http://www.osoco.org/weblogs/rael/
>
>
>
Re: Creating a Pluto 2.0 branch
Posted by "David H. DeWolf" <dd...@apache.org>.
No matter if it goes through the incubator or not, I'd like to make sure
the pluto committers have an opportunity to review the code before it's
committed. I was originally under the impression that the way this
development was going to work was that instead of a code "grant" or
dump, incremental modifications would take place in a branch - all
starting from a clean 1.1 branch.
If this is not the way it will work, we just need to iron out the
protocol - such as if the incubator is the right approach.
In terms of our contact with Torsten, I personally have had any
discussions other than trying to connect with him. I think the ideal
would be for him (and others on his team) to join the pluto-dev list and
allow us to all contribute to the discussions. . .
Just my 2 cents. . .
David
CDoremus@hannaford.com wrote:
>
> see below
> Carsten Ziegeler <cz...@apache.org> wrote on 08/24/2006 03:54:44 PM:
>
> > CDoremus@hannaford.com wrote:
> > > IBM has contracted with a group at the University of Jena in
> Germany to
> > > help create the reference implementation of JSR-286 to be hosted at
> > > Apache. David and I have been in contact with this group, which is
> headed
> > > by Torsten Dettborn, a member of the JSR-286 Expert Group.
> Torsten's group
> > > has done some work on the JSR-286 RI based on Pluto 1.1 that they
> want to
> > > contribute to our repository.
> > >
> > > Unless anyone objects, I would like to create a Pluto 2.0 branch in
> SVN to
> > > house the JSR-286 Reference Implementation code. The starting point
> for
> > > this branch will be the Pluto 1.1 code now in our SVN trunk.
> > >
> > > This is a great chance for the community to contribute to the
> JSR-286 RI
> > > and get an early look at an implementation of the developing
> JSR-286 spec.
> > I think every code donation must go through the incubator first, so we
> > should definitly first check with them.
> >
>
> They are contributing code that builds on our current code base. I do
> not see why it has to go through the incubation process. Like Tomcat,
> which revs up a version for a new servlet/JSP spec, we are creating a
> new version that corresponds to the new portlet spec.
> /Craig
>
>
> > Carsten
> > --
> > Carsten Ziegeler - Open Source Group, S&N AG
> > http://www.s-und-n.de
> > http://www.osoco.org/weblogs/rael/
Re: Creating a Pluto 2.0 branch
Posted by CD...@hannaford.com.
see below
Carsten Ziegeler <cz...@apache.org> wrote on 08/24/2006 03:54:44 PM:
> CDoremus@hannaford.com wrote:
> > IBM has contracted with a group at the University of Jena in Germany
to
> > help create the reference implementation of JSR-286 to be hosted at
> > Apache. David and I have been in contact with this group, which is
headed
> > by Torsten Dettborn, a member of the JSR-286 Expert Group. Torsten's
group
> > has done some work on the JSR-286 RI based on Pluto 1.1 that they want
to
> > contribute to our repository.
> >
> > Unless anyone objects, I would like to create a Pluto 2.0 branch in
SVN to
> > house the JSR-286 Reference Implementation code. The starting point
for
> > this branch will be the Pluto 1.1 code now in our SVN trunk.
> >
> > This is a great chance for the community to contribute to the JSR-286
RI
> > and get an early look at an implementation of the developing JSR-286
spec.
> I think every code donation must go through the incubator first, so we
> should definitly first check with them.
>
They are contributing code that builds on our current code base. I do not
see why it has to go through the incubation process. Like Tomcat, which
revs up a version for a new servlet/JSP spec, we are creating a new
version that corresponds to the new portlet spec.
/Craig
> Carsten
> --
> Carsten Ziegeler - Open Source Group, S&N AG
> http://www.s-und-n.de
> http://www.osoco.org/weblogs/rael/
Re: Creating a Pluto 2.0 branch
Posted by Carsten Ziegeler <cz...@apache.org>.
CDoremus@hannaford.com wrote:
> IBM has contracted with a group at the University of Jena in Germany to
> help create the reference implementation of JSR-286 to be hosted at
> Apache. David and I have been in contact with this group, which is headed
> by Torsten Dettborn, a member of the JSR-286 Expert Group. Torsten's group
> has done some work on the JSR-286 RI based on Pluto 1.1 that they want to
> contribute to our repository.
>
> Unless anyone objects, I would like to create a Pluto 2.0 branch in SVN to
> house the JSR-286 Reference Implementation code. The starting point for
> this branch will be the Pluto 1.1 code now in our SVN trunk.
>
> This is a great chance for the community to contribute to the JSR-286 RI
> and get an early look at an implementation of the developing JSR-286 spec.
I think every code donation must go through the incubator first, so we
should definitly first check with them.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/