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
