+1 to promoting 2.0-spi-refactoring to trunk.
>To: [email protected]
>From: Ate Douma <[EMAIL PROTECTED]>
>Date: 11/02/2008 06:03PM
>Subject: Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as
>the new Pluto 2.0.0-SNAPSHOT trunk
>
>Ate Douma wrote:
>> [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 :)
>>
>Craig and others,
>
>I've now merged *all* the above outstanding changes from trunk to the
>2.0-spi-refactoring branch, including the portlet-spec-2.0.css
>(r667292) as it was just one new file and a single line in the
>pluto-default-themes.jsp.
>
>I also threw in the Porlet 2.0 API javadocs (coming from the official
>JSR-286 download) to be made available online, just like the 1.0 API
>
>javadocs. (note: svn eol-style property caused me some problems with
>the commit, having me do it in several steps).
>
>AFAIK, the 2.0-spi-refactoring branch is now fully in sync with the
>trunk.
>
>Regards,
>
>Ate
>
>>>
>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
Thanks for doing the merges. I'm really looking forward to getting Pluto 2.0 out the door. However, due to a death in the family, I cannot offer much help right now.
/Craig
-----Ate Douma <[EMAIL PROTECTED]> wrote: ----->To: [email protected]
>From: Ate Douma <[EMAIL PROTECTED]>
>Date: 11/02/2008 06:03PM
>Subject: Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as
>the new Pluto 2.0.0-SNAPSHOT trunk
>
>Ate Douma wrote:
>> [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 :)
>>
>Craig and others,
>
>I've now merged *all* the above outstanding changes from trunk to the
>2.0-spi-refactoring branch, including the portlet-spec-2.0.css
>(r667292) as it was just one new file and a single line in the
>pluto-default-themes.jsp.
>
>I also threw in the Porlet 2.0 API javadocs (coming from the official
>JSR-286 download) to be made available online, just like the 1.0 API
>
>javadocs. (note: svn eol-style property caused me some problems with
>the commit, having me do it in several steps).
>
>AFAIK, the 2.0-spi-refactoring branch is now fully in sync with the
>trunk.
>
>Regards,
>
>Ate
>
>>>
>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
