Re: Recap of 286 RI / Pluto Conference Call

[Charles Severance <cs...@umich.edu>]

I have no vote so my opinion does not really matter - but I have a  
few clarifying questions:

Will the branch be a real branch or just different code?  I  
understand that Jena started with a version of Pluto 1.1- will they  
bring their patches to be current with the Pluto 1.1 trunk before  
they make the sandbox/2.0 branch?

If the answer is "yes - we will try to make it a real branch" - then  
the question is whether the branch will track the trunk going  
forward?  Who will do the merging as new code flows into the trunk to  
keep the branch and trunk in alignment?

If the answer is "no - this is just different code" - is there a time  
where the sandbox will be synchronized/merged so it is truly an  
offshoot of the trunk and captures the latest mods in the trunk?  Who  
will be responsible for the merging activity - will the Jena team  
merge in the trunk, or will we expect the the Pluto 1.1 team to merge  
the last six months of changes into the sandbox branch?

The answers to these questions might suggest a "good" time to get a  
1.1 release completed.

/Chuck

On Aug 31, 2006, at 7:08 AM, David H. DeWolf wrote:

> PMC and Pluto Developers,
>
> Yesterday Ate, Craig, Elliot, and Stefan and I from the portals  
> project were able to join the conference call which was proposed to  
> discuss 286 reference implementation with the EG Chair (Stefan) and  
> the Univ of Jena.  I wanted to provide a recap of what was discussed:
>
> First, Stefan quickly recapped the progress so far.  The bottom  
> line is that the development that has taken place so far is  
> considered a prototype and will not necessarily be a final  
> solution.  It was simple implemented as an experimentation to  
> validate the decisions made by the EG.  This work was done in  
> secret according to the guidelines of the JCP and it is recognized  
> that in order to be in compliance with Apache guidelines things  
> need to be more open from here forward.
>
> The rest of the discussion was based around moving forward.  We  
> would like to hear your feedback in regards to the following  
> proposal.  If there seem to be no objections, I will propose a vote  
> in the next couple of days:
>
> 1) Create a pluto-2.0 branch which is based off of the current  
> pluto trunk (pluto 1.1).  All pluto committers, as with any other  
> branch, will have immediate access to committing to this branch.  
> This includes Urlich who is (to some extent) part of the Univ. of  
> Jena team.
>
> 2) All code committed to the pluto-2.0 branch will follow normal  
> Apache review cycles.  Committers should review the committ logs  
> and validate it's the direction they'd like to see. Discussions  
> regarding the validity of changes should be discussed on the  
> mailing list and all -1s will apply as normal.
>
> 3) Any major overhauls or design decisions should be brought up on  
> the pluto developer mailing list.
>
> 4) ALL decisions should be made on the pluto developer mailing  
> list. Any discussions which are not done on the list should be  
> recapped on the list and open for discussion before being implemented.
>
> 5) Create a new version within JIRA (2.x) against which others  
> (including those in the Univ of Jena which aren't committers) can  
> provide patches.  Each of these patches will be considered and  
> discussed on a case by case basis on the pluto-dev list.
>
> 6) Allow collaboration through the Pluto wiki.  Ensure that all  
> collaboration is brought back to the pluto-dev list before a  
> decision is made.
>
>
> Ate, Craig and Elliot, please let me know if I missed anything.  
> Everyone else, please chime in and let us know your thoughts!
>
>
> Thanks,
>
>
> David
>
>
>

Re: Recap of 286 RI / Pluto Conference Call

[Charles Severance <cs...@umich.edu>]

Thanks - that helps - we will build from the current code in trunk  
and improve it keeping things in sync going forward.  Perfect.

/Chuck

On Aug 31, 2006, at 7:56 PM, David H. DeWolf wrote:

>
>
> Charles Severance wrote:
>> I have no vote so my opinion does not really matter - but I have a  
>> few clarifying questions:
>
> Yes it does. Your a member of the community and that's a class of  
> individuals that we're trying to build more of.  I hope that we  
> listen to our users. . .
>
>> Will the branch be a real branch or just different code?  I  
>> understand that Jena started with a version of Pluto 1.1- will  
>> they bring their patches to be current with the Pluto 1.1 trunk  
>> before they make the sandbox/2.0 branch?
>
> If the PMC decides to move in this direction then the branch will  
> be created from the current trunk (which is 1.1) - regardless of  
> any work that's been done anywhere else.  That will be the baseline  
> and all else will be added per our normal mechanisms.
>
> In short, any patches should be created off of the newly created  
> branch which will be 100% up to date with the trunk at the time of  
> creation.
>
>> If the answer is "yes - we will try to make it a real branch" -  
>> then the question is whether the branch will track the trunk going  
>> forward?  Who will do the merging as new code flows into the trunk  
>> to keep the branch and trunk in alignment?
>
> One proposal has been brought up that we actually branch 1.1 for  
> maintenance and full GA release and that we keep the trunk as the  
> cutting edge.  Either way, we'll need to figure out how and when  
> this merge will take place.
>
>> If the answer is "no - this is just different code" - is there a  
>> time where the sandbox will be synchronized/merged so it is truly  
>> an offshoot of the trunk and captures the latest mods in the  
>> trunk?  Who will be responsible for the merging activity - will  
>> the Jena team merge in the trunk, or will we expect the the Pluto  
>> 1.1 team to merge the last six months of changes into the sandbox  
>> branch?
>
> This is not different code, it's a series of enhancements to the  
> existing code.  Either way, all commits will be made by Pluto  
> committers.  Only Urlich overlaps the teams.
>
>> The answers to these questions might suggest a "good" time to get  
>> a 1.1 release completed.
>
> I think we're nearing another beta release no matter what happens  
> with the RI.  Thanks to Elliot, Craig, and several others that have  
> submitted patches, we've had a flurry of activity lately.
>
> Hope that helps,
>
>
> David

Re: Recap of 286 RI / Pluto Conference Call

["David H. DeWolf" <dd...@apache.org>]

Charles Severance wrote:
> I have no vote so my opinion does not really matter - but I have a few 
> clarifying questions:

Yes it does. Your a member of the community and that's a class of 
individuals that we're trying to build more of.  I hope that we listen 
to our users. . .

> 
> Will the branch be a real branch or just different code?  I understand 
> that Jena started with a version of Pluto 1.1- will they bring their 
> patches to be current with the Pluto 1.1 trunk before they make the 
> sandbox/2.0 branch?

If the PMC decides to move in this direction then the branch will be 
created from the current trunk (which is 1.1) - regardless of any work 
that's been done anywhere else.  That will be the baseline and all else 
will be added per our normal mechanisms.

In short, any patches should be created off of the newly created branch 
which will be 100% up to date with the trunk at the time of creation.

> 
> If the answer is "yes - we will try to make it a real branch" - then the 
> question is whether the branch will track the trunk going forward?  Who 
> will do the merging as new code flows into the trunk to keep the branch 
> and trunk in alignment?

One proposal has been brought up that we actually branch 1.1 for 
maintenance and full GA release and that we keep the trunk as the 
cutting edge.  Either way, we'll need to figure out how and when this 
merge will take place.

> 
> If the answer is "no - this is just different code" - is there a time 
> where the sandbox will be synchronized/merged so it is truly an offshoot 
> of the trunk and captures the latest mods in the trunk?  Who will be 
> responsible for the merging activity - will the Jena team merge in the 
> trunk, or will we expect the the Pluto 1.1 team to merge the last six 
> months of changes into the sandbox branch?

This is not different code, it's a series of enhancements to the 
existing code.  Either way, all commits will be made by Pluto 
committers.  Only Urlich overlaps the teams.

> 
> The answers to these questions might suggest a "good" time to get a 1.1 
> release completed.

I think we're nearing another beta release no matter what happens with 
the RI.  Thanks to Elliot, Craig, and several others that have submitted 
patches, we've had a flurry of activity lately.

Hope that helps,


David

> 
> /Chuck
> 
> On Aug 31, 2006, at 7:08 AM, David H. DeWolf wrote:
> 
>> PMC and Pluto Developers,
>>
>> Yesterday Ate, Craig, Elliot, and Stefan and I from the portals 
>> project were able to join the conference call which was proposed to 
>> discuss 286 reference implementation with the EG Chair (Stefan) and 
>> the Univ of Jena.  I wanted to provide a recap of what was discussed:
>>
>> First, Stefan quickly recapped the progress so far.  The bottom line 
>> is that the development that has taken place so far is considered a 
>> prototype and will not necessarily be a final solution.  It was simple 
>> implemented as an experimentation to validate the decisions made by 
>> the EG.  This work was done in secret according to the guidelines of 
>> the JCP and it is recognized that in order to be in compliance with 
>> Apache guidelines things need to be more open from here forward.
>>
>> The rest of the discussion was based around moving forward.  We would 
>> like to hear your feedback in regards to the following proposal.  If 
>> there seem to be no objections, I will propose a vote in the next 
>> couple of days:
>>
>> 1) Create a pluto-2.0 branch which is based off of the current pluto 
>> trunk (pluto 1.1).  All pluto committers, as with any other branch, 
>> will have immediate access to committing to this branch. This includes 
>> Urlich who is (to some extent) part of the Univ. of Jena team.
>>
>> 2) All code committed to the pluto-2.0 branch will follow normal 
>> Apache review cycles.  Committers should review the committ logs and 
>> validate it's the direction they'd like to see. Discussions regarding 
>> the validity of changes should be discussed on the mailing list and 
>> all -1s will apply as normal.
>>
>> 3) Any major overhauls or design decisions should be brought up on the 
>> pluto developer mailing list.
>>
>> 4) ALL decisions should be made on the pluto developer mailing list. 
>> Any discussions which are not done on the list should be recapped on 
>> the list and open for discussion before being implemented.
>>
>> 5) Create a new version within JIRA (2.x) against which others 
>> (including those in the Univ of Jena which aren't committers) can 
>> provide patches.  Each of these patches will be considered and 
>> discussed on a case by case basis on the pluto-dev list.
>>
>> 6) Allow collaboration through the Pluto wiki.  Ensure that all 
>> collaboration is brought back to the pluto-dev list before a decision 
>> is made.
>>
>>
>> Ate, Craig and Elliot, please let me know if I missed anything. 
>> Everyone else, please chime in and let us know your thoughts!
>>
>>
>> Thanks,
>>
>>
>> David
>>
>>
>>
> 
>