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
