[EMAIL PROTECTED] wrote:
This seems to indicate that you will be replacing the trunk with the
2.0-refactoring branch rather than doing a merge. Is that true? If so,
there are some things that were applied to the trunk since the branch was
created that were not applied to the branch. Some of them are my fault. For
instance, I added portlet-spec-2.0.css to the trunk (and references in JSP
page(s)), but not to the 2.0-refactoring branch. I will fix this
discrepancy, but there should be a diff done between trunk and the branch
to see what the major differences are before the replacement is done.
Hi Graig,
Yes. I'm proposing to replace the trunk (after saving it as a branch itself)
with the 2.0-spi-refactoring branch.
While there has been some changes to the trunk, most of them are already
applied to the branch too.
And as I'd like to keep track of the svn history of all the changes made to the branch, merging in from the branch isn't the best way of
doing that (if not extremely error prone already).
Of course, you are right we need to make sure the branch actually is up to date
with the trunk changes too.
I was under the impression that to be the case already but after your comment I
did run a check and found a few which haven't been applied.
Besides the portlet-spec-2.0.css (r667292) you mentioned already I found the following which should be the complete set of outstanding
changes to merge to the branch before we can replace trunk with it:
http://svn.apache.org/viewvc?rev=657367&view=rev (merging in doc changes from
1.1.x branch)
http://svn.apache.org/viewvc?rev=667292&view=rev (your portlet-spec-2.0.css)
http://svn.apache.org/viewvc?rev=671123&view=rev (site xdoc update)
http://svn.apache.org/viewvc?rev=671124&view=rev (site xdoc update)
http://svn.apache.org/viewvc?rev=678338&view=rev (site xdoc update)
http://svn.apache.org/viewvc?rev=685023&view=rev (Add Eric Dalquist to KEYS)
http://svn.apache.org/viewvc?rev=685529&view=rev (site xdoc update)
As you see, this is mostly outstanding changes for the xdocs, besides the
portlet 2.0 css change which you will apply to the branch, right?
I'll take care of the other merges which should be easy enough :)
This comment does not diminish my high opinion of the the work you have
done on the 2.0-refactoring branch. Pluto will be a much better product for
having your contributions added to it. Thank you!
Thank you for you support too Graig!
I gather this mean +1 from you (after the above merges are done), right?
Regards,
Ate
/Craig
Ate Douma <[EMAIL PROTECTED]> wrote on 10/31/2008 09:38:52 PM:
Finally,
The 2.0-spi-refactoring branch which we started for issue PLUTO-481, see
http://issues.apache.org/jira/browse/PLUTO-481, is in our view now
ready to be voted upon for promotion as the new Pluto 2.0.0-SNAPSHOT
trunk.
After many, many refactoring iterations, we now reached a clean and
stabile new Pluto 2.0 API and SPI interfaces which allows us to embed
Pluto again in the Jetspeed-2 Portal (still under development in its
own jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
While there are plenty of features which need "improvement" and of
course lots of other cleanup/fixing issues, we don't expect *major*
changes in the API/SPI further on.
There are also still a few minor TCK 2.0 issues open, but those
result from earlier changes on the trunk before this refactoring.
The refactoring branch actually is already (again) more compliant
than the trunk itself.
So, we regard this task, which was primarily targeted at getting
Pluto embeddable again for other portals and Jetspeed specifically, now
as
finished.
Once this vote passes, we propose to *save* the current trunk by
moving it to a new branch called "pre-2.0-refactoring-trunk-move".
Thereafter, the 2.0-spi-refactoring branch can be moved/promoted to
trunk.
We'd like to ask all the active Apache Portals committers and other
interested members of our community to review and cast your vote now!
With kind regards,
Ate Douma
David Taylor
