You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2015/07/04 06:17:19 UTC
[VOTE] Release UIMA SDK 2.8.0 rc4
Hi,
RC 4 is the same as rc3 except for this Jira and its fix:
https://issues.apache.org/jira/browse/UIMA-4501
Previous changes: updating the property to make the right issues-fixed, the copy
iterator issue(s), and mainly other bug fixes, but includes two new things: one
is the index flattening for sorted indexes, and the other is the improved Java
Cas view that's part of the document analyzer.
The list of changes in Jira:
https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.8.0SDK%20AND%20project%20%3D%20UIMA
The source and binary zip/tars and the Eclipse update site are staged to
http://people.apache.org/~schor/uima-release-candidates/uimaj-2.8.0-rc4
<http://people.apache.org/%7Eschor/uima-release-candidates/uimaj-2.8.0-rc4>
The Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapacheuima-1059
The SVN tags are here:
http://svn.apache.org/repos/asf/uima/uimaj/tags/uimaj-2.8.0/
and for the Eclipse Update Site:
https://people.apache.org/~schor/uima-release-candidates/uimaj-2.8.0-rc4/eclipse-update-site/uimaj/
<https://people.apache.org/%7Eschor/uima-release-candidates/uimaj-2.8.0-rc4/eclipse-update-site/uimaj/>
See http://uima.apache.org/testing-builds.html for suggestions on how to test
release candidates.
Please vote on release:
[ ] +1 OK to release
[ ] 0 Don't care
[ ] -1 Not OK to release, because ...
Thanks.
-Marshall
Re: [VOTE] Release UIMA SDK 2.8.0 rc4
Posted by Marshall Schor <ms...@schor.com>.
I think Burn has found a significant issue. I'll probably cancel this vote.
I've started another thread to discuss it.
-Marshall
On 7/7/2015 3:10 PM, Burn Lewis wrote:
> So since this is not a critical API change we don't have to update the
> major version number :)
> I'll see how much of our code it affects.
>
> Burn.
>
> On Tue, Jul 7, 2015 at 10:14 AM, Marshall Schor <ms...@schor.com> wrote:
>
>> This was changed on purpose to make things more consumable; see the comment
>> chain toward the bottom of Jira
>> https://issues.apache.org/jira/browse/UIMA-4299
>>
>> It looks like this would affect cases where <TOP> was used.
>>
>> Although I at first thought that TOP would be better, it cannot be used
>> because
>> of the meaning of get-*all*-indexed-fs - some of the Feature Structures
>> returned
>> may not be JCas style cover classes - in case there was no JCas class
>> defined
>> for those types. So it has to be the more general FeatureStructure.
>>
>> For example, if it was of type TOP, then you could use a method on this
>> which
>> exists only for TOP and not for FeatureStructure (e.g.,
>> myTopInstance.addToIndexes()).
>>
>> Is this a blocker? I agree it needs to be documented, and if it's not a
>> blocker, it can be documented:
>> a) in the announcement
>> b) in the web-site version of the RELEASE_NOTES
>>
>> If it is a blocker, we'll document it in the manual, and the RELEASE_NOTES.
>>
>> By itself, I would tend to view this as not a blocker.
>>
>> -Marshall
>>
>> On 7/7/2015 9:39 AM, Richard Eckart de Castilho wrote:
>>> Looks like the static byte-code analysis done by the Semantic Versioning
>> plug-in
>>> doesn't catch that :/
>>>
>>> So I guess, we have a binary-compatible change that is not
>> source-compatible.
>>> -- Richard
>>>
>>> On 07.07.2015, at 15:36, Burn Lewis <bu...@gmail.com> wrote:
>>>
>>>> The release notes say no API changes, but the return type of
>>>> org.apache.uima.jcas.getAllIndexedFS has changed from FSIterator<TOP>
>> to
>>>> FSIterator<FeatureStructure> which has produced a compile error in our
>> code.
>>>> On Mon, Jul 6, 2015 at 3:57 PM, Marshall Schor <ms...@schor.com> wrote:
>>>>
>>>>> thanks, again :-) .
>>>>>
>>>>> I remember that the lib folder jar names were debated 6-7 years ago.
>> The
>>>>> debate
>>>>> centered more around whether or not to adopt the standard of how these
>>>>> jars are
>>>>> named in the Maven artifact repository.
>>>>> e.g.
>>>>> maven repo: uimaj-core-2.7.0.jar
>>>>> lib: uima-core.jar
>>>>>
>>>>> Not only is the "j" different, but the maven repo has the version
>> appended.
>>>>> Also, https://issues.apache.org/jira/browse/UIMA-355 has some
>> comments on
>>>>> renaming.
>>>>>
>>>>> You can find this discussion in the mail archives. For instance,
>> search
>>>>> uima.markmail.org with the keywords:
>>>>> naming uima-core uima-355
>>>>>
>>>>> The bottom line for me sort of nets out to the following:
>>>>>
>>>>> 1) Renaming the Jars to follow the Maven names would make things more
>>>>> consistent
>>>>> 2) Renaming the Jars to follow the Maven names would somewhat impact
>> our
>>>>> users
>>>>> (who might be hard-coding the jar name, which for now, doesn't change
>> in
>>>>> the
>>>>> lib/ dir of the binary distribution).
>>>>>
>>>>> When I weight these two reasons, I feel it's more important not to
>> impact
>>>>> our
>>>>> users, given the benefit is only one of some consistency.
>>>>> But if there were no impact to the users, I would be fine with changing
>>>>> this.
>>>>>
>>>>> -Marshall
>>>>>
>>>>>
>>>>>
>>>>> On 7/6/2015 12:52 PM, Richard Eckart de Castilho wrote:
>>>>>> Reason for the missing issuesFixed was that I was looking at a locally
>>>>> built
>>>>>> version (without -Papache-release) at that moment.
>>>>>>
>>>>>> Re-did spot check of licenses/notices against the ZIP you provided -
>>>>> still
>>>>>> looks all ok and the issuesFixed is there.
>>>>>>
>>>>>> So I maintain the +1.
>>>>>>
>>>>>> Btw. I think I pointed this out in the past: why not switch from the
>>>>>> "uima-XXX" naming to the proper "uimaj-XXX" naming in the lib folder?
>>>>>> The files identify themselves as "uimaj-XXX" in their NOTICE files.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> -- Richard
>>>>>>
>>>>>> On 06.07.2015, at 16:50, Marshall Schor <ms...@schor.com> wrote:
>>>>>>
>>>>>>> Thanks for the quick vote!
>>>>>>>
>>>>>>> On the point about the link to "issues fixed" in RELEASE_NOTES.html
>> of
>>>>> the zip
>>>>>>> distribution - I cannot reproduce this.
>>>>>>> I tried unzipping the uimaj-2.8.0-bin.zip, then opening
>>>>> RELEASE_NOTES.html, then
>>>>>>> clicking on the table-of-contents link " List of JIRA Issues Fixed in
>>>>> this
>>>>>>> Release", and then clicked on "issuesFixed/jira-report.hmtl" under
>> the
>>>>> heading
>>>>>>> "Full list of JIRA Issues Fixed in this Release".
>>>>>>>
>>>>>>> I also tried the same thing unzipping the
>>>>> uimaj-2.8.0-source-release.zip. Both
>>>>>>> worked OK for me.
>>>>>>>
>>>>>>> Can you say more precisely what failed? The zips both included a
>>>>> directory
>>>>>>> "issuesFixed", and within that, the file "jira-report.html". (My test
>>>>> was on
>>>>>>> Windows).
>>>>>>>
>>>>>>> -Marshall
>>>>>>>
>>>>>>> On 7/5/2015 5:10 PM, Richard Eckart de Castilho wrote:
>>>>>>>> Built from SVN tag with empty .m2 using JDK 7 on OS X - OK
>>>>>>>>
>>>>>>>> Spot check for licenses and notices - OK
>>>>>>>>
>>>>>>>> Built Apache uimaFIT trunk against this RC - OK
>>>>>>>>
>>>>>>>> Built other software against this RC - OK
>>>>>>>>
>>>>>>>> Spot check signatures - look OK (still need to get into the web of
>>>>> trust...)
>>>>>>>> [X] +1 OK to release
>>>>>>>>
>>>>>>>>
>>>>>>>> Link to "issues fixed" in RELEASE_NOTES.html of ZIP distribution
>> does
>>>>> not work. Shouldn't there be such a file in the ZIP? - Not critical,
>> but
>>>>> should be fixed in next release.
>>>>>>>> Btw. we have many issues that were marked as "resolved" or "closed"
>>>>> but that do not have an assignee:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(EMPTY)
>>>>>>>> I fixed the assignee on those issues that I had initially reported.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> -- Richard
>>>>>>>>
>>>>>>>> On 04.07.2015, at 20:49, Marshall Schor <ms...@schor.com> wrote:
>>>>>>>>
>>>>>>>>> signatures - OK
>>>>>>>>>
>>>>>>>>> Source compare with tag: OK
>>>>>>>>>
>>>>>>>>> Install into Eclipse Luna: OK; tested by running the Component
>>>>> Descriptor Editor
>>>>>>>>> Build from sources - OK (needs Java 7, not 8 due to javadoc issues
>> -
>>>>> not a blocker)
>>>>>>>>> Issues Fixed - OK
>>>>>>>>>
>>>>>>>>> spot checked licenses and notices - OK
>>>>>>>>>
>>>>>>>>> from binary distribution, ran adjust example paths, and document
>>>>> analyzer, and
>>>>>>>>> Java results viewer (showing new Features view) - OK
>>>>>>>>>
>>>>>>>>> [X] +1 OK to release
>>>>>>>>>
>>>>>>>>> -Marshall Schor
>>
Re: [VOTE] Release UIMA SDK 2.8.0 rc4
Posted by Burn Lewis <bu...@gmail.com>.
So since this is not a critical API change we don't have to update the
major version number :)
I'll see how much of our code it affects.
Burn.
On Tue, Jul 7, 2015 at 10:14 AM, Marshall Schor <ms...@schor.com> wrote:
> This was changed on purpose to make things more consumable; see the comment
> chain toward the bottom of Jira
> https://issues.apache.org/jira/browse/UIMA-4299
>
> It looks like this would affect cases where <TOP> was used.
>
> Although I at first thought that TOP would be better, it cannot be used
> because
> of the meaning of get-*all*-indexed-fs - some of the Feature Structures
> returned
> may not be JCas style cover classes - in case there was no JCas class
> defined
> for those types. So it has to be the more general FeatureStructure.
>
> For example, if it was of type TOP, then you could use a method on this
> which
> exists only for TOP and not for FeatureStructure (e.g.,
> myTopInstance.addToIndexes()).
>
> Is this a blocker? I agree it needs to be documented, and if it's not a
> blocker, it can be documented:
> a) in the announcement
> b) in the web-site version of the RELEASE_NOTES
>
> If it is a blocker, we'll document it in the manual, and the RELEASE_NOTES.
>
> By itself, I would tend to view this as not a blocker.
>
> -Marshall
>
> On 7/7/2015 9:39 AM, Richard Eckart de Castilho wrote:
> > Looks like the static byte-code analysis done by the Semantic Versioning
> plug-in
> > doesn't catch that :/
> >
> > So I guess, we have a binary-compatible change that is not
> source-compatible.
> >
> > -- Richard
> >
> > On 07.07.2015, at 15:36, Burn Lewis <bu...@gmail.com> wrote:
> >
> >> The release notes say no API changes, but the return type of
> >> org.apache.uima.jcas.getAllIndexedFS has changed from FSIterator<TOP>
> to
> >> FSIterator<FeatureStructure> which has produced a compile error in our
> code.
> >>
> >> On Mon, Jul 6, 2015 at 3:57 PM, Marshall Schor <ms...@schor.com> wrote:
> >>
> >>> thanks, again :-) .
> >>>
> >>> I remember that the lib folder jar names were debated 6-7 years ago.
> The
> >>> debate
> >>> centered more around whether or not to adopt the standard of how these
> >>> jars are
> >>> named in the Maven artifact repository.
> >>> e.g.
> >>> maven repo: uimaj-core-2.7.0.jar
> >>> lib: uima-core.jar
> >>>
> >>> Not only is the "j" different, but the maven repo has the version
> appended.
> >>>
> >>> Also, https://issues.apache.org/jira/browse/UIMA-355 has some
> comments on
> >>> renaming.
> >>>
> >>> You can find this discussion in the mail archives. For instance,
> search
> >>> uima.markmail.org with the keywords:
> >>> naming uima-core uima-355
> >>>
> >>> The bottom line for me sort of nets out to the following:
> >>>
> >>> 1) Renaming the Jars to follow the Maven names would make things more
> >>> consistent
> >>> 2) Renaming the Jars to follow the Maven names would somewhat impact
> our
> >>> users
> >>> (who might be hard-coding the jar name, which for now, doesn't change
> in
> >>> the
> >>> lib/ dir of the binary distribution).
> >>>
> >>> When I weight these two reasons, I feel it's more important not to
> impact
> >>> our
> >>> users, given the benefit is only one of some consistency.
> >>> But if there were no impact to the users, I would be fine with changing
> >>> this.
> >>>
> >>> -Marshall
> >>>
> >>>
> >>>
> >>> On 7/6/2015 12:52 PM, Richard Eckart de Castilho wrote:
> >>>> Reason for the missing issuesFixed was that I was looking at a locally
> >>> built
> >>>> version (without -Papache-release) at that moment.
> >>>>
> >>>> Re-did spot check of licenses/notices against the ZIP you provided -
> >>> still
> >>>> looks all ok and the issuesFixed is there.
> >>>>
> >>>> So I maintain the +1.
> >>>>
> >>>> Btw. I think I pointed this out in the past: why not switch from the
> >>>> "uima-XXX" naming to the proper "uimaj-XXX" naming in the lib folder?
> >>>> The files identify themselves as "uimaj-XXX" in their NOTICE files.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> -- Richard
> >>>>
> >>>> On 06.07.2015, at 16:50, Marshall Schor <ms...@schor.com> wrote:
> >>>>
> >>>>> Thanks for the quick vote!
> >>>>>
> >>>>> On the point about the link to "issues fixed" in RELEASE_NOTES.html
> of
> >>> the zip
> >>>>> distribution - I cannot reproduce this.
> >>>>> I tried unzipping the uimaj-2.8.0-bin.zip, then opening
> >>> RELEASE_NOTES.html, then
> >>>>> clicking on the table-of-contents link " List of JIRA Issues Fixed in
> >>> this
> >>>>> Release", and then clicked on "issuesFixed/jira-report.hmtl" under
> the
> >>> heading
> >>>>> "Full list of JIRA Issues Fixed in this Release".
> >>>>>
> >>>>> I also tried the same thing unzipping the
> >>> uimaj-2.8.0-source-release.zip. Both
> >>>>> worked OK for me.
> >>>>>
> >>>>> Can you say more precisely what failed? The zips both included a
> >>> directory
> >>>>> "issuesFixed", and within that, the file "jira-report.html". (My test
> >>> was on
> >>>>> Windows).
> >>>>>
> >>>>> -Marshall
> >>>>>
> >>>>> On 7/5/2015 5:10 PM, Richard Eckart de Castilho wrote:
> >>>>>> Built from SVN tag with empty .m2 using JDK 7 on OS X - OK
> >>>>>>
> >>>>>> Spot check for licenses and notices - OK
> >>>>>>
> >>>>>> Built Apache uimaFIT trunk against this RC - OK
> >>>>>>
> >>>>>> Built other software against this RC - OK
> >>>>>>
> >>>>>> Spot check signatures - look OK (still need to get into the web of
> >>> trust...)
> >>>>>> [X] +1 OK to release
> >>>>>>
> >>>>>>
> >>>>>> Link to "issues fixed" in RELEASE_NOTES.html of ZIP distribution
> does
> >>> not work. Shouldn't there be such a file in the ZIP? - Not critical,
> but
> >>> should be fixed in next release.
> >>>>>> Btw. we have many issues that were marked as "resolved" or "closed"
> >>> but that do not have an assignee:
> >>>>>>
> >>>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(EMPTY)
> >>>>>> I fixed the assignee on those issues that I had initially reported.
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>> -- Richard
> >>>>>>
> >>>>>> On 04.07.2015, at 20:49, Marshall Schor <ms...@schor.com> wrote:
> >>>>>>
> >>>>>>> signatures - OK
> >>>>>>>
> >>>>>>> Source compare with tag: OK
> >>>>>>>
> >>>>>>> Install into Eclipse Luna: OK; tested by running the Component
> >>> Descriptor Editor
> >>>>>>> Build from sources - OK (needs Java 7, not 8 due to javadoc issues
> -
> >>> not a blocker)
> >>>>>>> Issues Fixed - OK
> >>>>>>>
> >>>>>>> spot checked licenses and notices - OK
> >>>>>>>
> >>>>>>> from binary distribution, ran adjust example paths, and document
> >>> analyzer, and
> >>>>>>> Java results viewer (showing new Features view) - OK
> >>>>>>>
> >>>>>>> [X] +1 OK to release
> >>>>>>>
> >>>>>>> -Marshall Schor
> >>>
> >
>
>
Re: [VOTE] Release UIMA SDK 2.8.0 rc4
Posted by Marshall Schor <ms...@schor.com>.
This was changed on purpose to make things more consumable; see the comment
chain toward the bottom of Jira https://issues.apache.org/jira/browse/UIMA-4299
It looks like this would affect cases where <TOP> was used.
Although I at first thought that TOP would be better, it cannot be used because
of the meaning of get-*all*-indexed-fs - some of the Feature Structures returned
may not be JCas style cover classes - in case there was no JCas class defined
for those types. So it has to be the more general FeatureStructure.
For example, if it was of type TOP, then you could use a method on this which
exists only for TOP and not for FeatureStructure (e.g.,
myTopInstance.addToIndexes()).
Is this a blocker? I agree it needs to be documented, and if it's not a
blocker, it can be documented:
a) in the announcement
b) in the web-site version of the RELEASE_NOTES
If it is a blocker, we'll document it in the manual, and the RELEASE_NOTES.
By itself, I would tend to view this as not a blocker.
-Marshall
On 7/7/2015 9:39 AM, Richard Eckart de Castilho wrote:
> Looks like the static byte-code analysis done by the Semantic Versioning plug-in
> doesn't catch that :/
>
> So I guess, we have a binary-compatible change that is not source-compatible.
>
> -- Richard
>
> On 07.07.2015, at 15:36, Burn Lewis <bu...@gmail.com> wrote:
>
>> The release notes say no API changes, but the return type of
>> org.apache.uima.jcas.getAllIndexedFS has changed from FSIterator<TOP> to
>> FSIterator<FeatureStructure> which has produced a compile error in our code.
>>
>> On Mon, Jul 6, 2015 at 3:57 PM, Marshall Schor <ms...@schor.com> wrote:
>>
>>> thanks, again :-) .
>>>
>>> I remember that the lib folder jar names were debated 6-7 years ago. The
>>> debate
>>> centered more around whether or not to adopt the standard of how these
>>> jars are
>>> named in the Maven artifact repository.
>>> e.g.
>>> maven repo: uimaj-core-2.7.0.jar
>>> lib: uima-core.jar
>>>
>>> Not only is the "j" different, but the maven repo has the version appended.
>>>
>>> Also, https://issues.apache.org/jira/browse/UIMA-355 has some comments on
>>> renaming.
>>>
>>> You can find this discussion in the mail archives. For instance, search
>>> uima.markmail.org with the keywords:
>>> naming uima-core uima-355
>>>
>>> The bottom line for me sort of nets out to the following:
>>>
>>> 1) Renaming the Jars to follow the Maven names would make things more
>>> consistent
>>> 2) Renaming the Jars to follow the Maven names would somewhat impact our
>>> users
>>> (who might be hard-coding the jar name, which for now, doesn't change in
>>> the
>>> lib/ dir of the binary distribution).
>>>
>>> When I weight these two reasons, I feel it's more important not to impact
>>> our
>>> users, given the benefit is only one of some consistency.
>>> But if there were no impact to the users, I would be fine with changing
>>> this.
>>>
>>> -Marshall
>>>
>>>
>>>
>>> On 7/6/2015 12:52 PM, Richard Eckart de Castilho wrote:
>>>> Reason for the missing issuesFixed was that I was looking at a locally
>>> built
>>>> version (without -Papache-release) at that moment.
>>>>
>>>> Re-did spot check of licenses/notices against the ZIP you provided -
>>> still
>>>> looks all ok and the issuesFixed is there.
>>>>
>>>> So I maintain the +1.
>>>>
>>>> Btw. I think I pointed this out in the past: why not switch from the
>>>> "uima-XXX" naming to the proper "uimaj-XXX" naming in the lib folder?
>>>> The files identify themselves as "uimaj-XXX" in their NOTICE files.
>>>>
>>>> Cheers,
>>>>
>>>> -- Richard
>>>>
>>>> On 06.07.2015, at 16:50, Marshall Schor <ms...@schor.com> wrote:
>>>>
>>>>> Thanks for the quick vote!
>>>>>
>>>>> On the point about the link to "issues fixed" in RELEASE_NOTES.html of
>>> the zip
>>>>> distribution - I cannot reproduce this.
>>>>> I tried unzipping the uimaj-2.8.0-bin.zip, then opening
>>> RELEASE_NOTES.html, then
>>>>> clicking on the table-of-contents link " List of JIRA Issues Fixed in
>>> this
>>>>> Release", and then clicked on "issuesFixed/jira-report.hmtl" under the
>>> heading
>>>>> "Full list of JIRA Issues Fixed in this Release".
>>>>>
>>>>> I also tried the same thing unzipping the
>>> uimaj-2.8.0-source-release.zip. Both
>>>>> worked OK for me.
>>>>>
>>>>> Can you say more precisely what failed? The zips both included a
>>> directory
>>>>> "issuesFixed", and within that, the file "jira-report.html". (My test
>>> was on
>>>>> Windows).
>>>>>
>>>>> -Marshall
>>>>>
>>>>> On 7/5/2015 5:10 PM, Richard Eckart de Castilho wrote:
>>>>>> Built from SVN tag with empty .m2 using JDK 7 on OS X - OK
>>>>>>
>>>>>> Spot check for licenses and notices - OK
>>>>>>
>>>>>> Built Apache uimaFIT trunk against this RC - OK
>>>>>>
>>>>>> Built other software against this RC - OK
>>>>>>
>>>>>> Spot check signatures - look OK (still need to get into the web of
>>> trust...)
>>>>>> [X] +1 OK to release
>>>>>>
>>>>>>
>>>>>> Link to "issues fixed" in RELEASE_NOTES.html of ZIP distribution does
>>> not work. Shouldn't there be such a file in the ZIP? - Not critical, but
>>> should be fixed in next release.
>>>>>> Btw. we have many issues that were marked as "resolved" or "closed"
>>> but that do not have an assignee:
>>>>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(EMPTY)
>>>>>> I fixed the assignee on those issues that I had initially reported.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> -- Richard
>>>>>>
>>>>>> On 04.07.2015, at 20:49, Marshall Schor <ms...@schor.com> wrote:
>>>>>>
>>>>>>> signatures - OK
>>>>>>>
>>>>>>> Source compare with tag: OK
>>>>>>>
>>>>>>> Install into Eclipse Luna: OK; tested by running the Component
>>> Descriptor Editor
>>>>>>> Build from sources - OK (needs Java 7, not 8 due to javadoc issues -
>>> not a blocker)
>>>>>>> Issues Fixed - OK
>>>>>>>
>>>>>>> spot checked licenses and notices - OK
>>>>>>>
>>>>>>> from binary distribution, ran adjust example paths, and document
>>> analyzer, and
>>>>>>> Java results viewer (showing new Features view) - OK
>>>>>>>
>>>>>>> [X] +1 OK to release
>>>>>>>
>>>>>>> -Marshall Schor
>>>
>
Re: [VOTE] Release UIMA SDK 2.8.0 rc4
Posted by Richard Eckart de Castilho <re...@apache.org>.
Looks like the static byte-code analysis done by the Semantic Versioning plug-in
doesn't catch that :/
So I guess, we have a binary-compatible change that is not source-compatible.
-- Richard
On 07.07.2015, at 15:36, Burn Lewis <bu...@gmail.com> wrote:
> The release notes say no API changes, but the return type of
> org.apache.uima.jcas.getAllIndexedFS has changed from FSIterator<TOP> to
> FSIterator<FeatureStructure> which has produced a compile error in our code.
>
> On Mon, Jul 6, 2015 at 3:57 PM, Marshall Schor <ms...@schor.com> wrote:
>
>> thanks, again :-) .
>>
>> I remember that the lib folder jar names were debated 6-7 years ago. The
>> debate
>> centered more around whether or not to adopt the standard of how these
>> jars are
>> named in the Maven artifact repository.
>> e.g.
>> maven repo: uimaj-core-2.7.0.jar
>> lib: uima-core.jar
>>
>> Not only is the "j" different, but the maven repo has the version appended.
>>
>> Also, https://issues.apache.org/jira/browse/UIMA-355 has some comments on
>> renaming.
>>
>> You can find this discussion in the mail archives. For instance, search
>> uima.markmail.org with the keywords:
>> naming uima-core uima-355
>>
>> The bottom line for me sort of nets out to the following:
>>
>> 1) Renaming the Jars to follow the Maven names would make things more
>> consistent
>> 2) Renaming the Jars to follow the Maven names would somewhat impact our
>> users
>> (who might be hard-coding the jar name, which for now, doesn't change in
>> the
>> lib/ dir of the binary distribution).
>>
>> When I weight these two reasons, I feel it's more important not to impact
>> our
>> users, given the benefit is only one of some consistency.
>> But if there were no impact to the users, I would be fine with changing
>> this.
>>
>> -Marshall
>>
>>
>>
>> On 7/6/2015 12:52 PM, Richard Eckart de Castilho wrote:
>>> Reason for the missing issuesFixed was that I was looking at a locally
>> built
>>> version (without -Papache-release) at that moment.
>>>
>>> Re-did spot check of licenses/notices against the ZIP you provided -
>> still
>>> looks all ok and the issuesFixed is there.
>>>
>>> So I maintain the +1.
>>>
>>> Btw. I think I pointed this out in the past: why not switch from the
>>> "uima-XXX" naming to the proper "uimaj-XXX" naming in the lib folder?
>>> The files identify themselves as "uimaj-XXX" in their NOTICE files.
>>>
>>> Cheers,
>>>
>>> -- Richard
>>>
>>> On 06.07.2015, at 16:50, Marshall Schor <ms...@schor.com> wrote:
>>>
>>>> Thanks for the quick vote!
>>>>
>>>> On the point about the link to "issues fixed" in RELEASE_NOTES.html of
>> the zip
>>>> distribution - I cannot reproduce this.
>>>> I tried unzipping the uimaj-2.8.0-bin.zip, then opening
>> RELEASE_NOTES.html, then
>>>> clicking on the table-of-contents link " List of JIRA Issues Fixed in
>> this
>>>> Release", and then clicked on "issuesFixed/jira-report.hmtl" under the
>> heading
>>>> "Full list of JIRA Issues Fixed in this Release".
>>>>
>>>> I also tried the same thing unzipping the
>> uimaj-2.8.0-source-release.zip. Both
>>>> worked OK for me.
>>>>
>>>> Can you say more precisely what failed? The zips both included a
>> directory
>>>> "issuesFixed", and within that, the file "jira-report.html". (My test
>> was on
>>>> Windows).
>>>>
>>>> -Marshall
>>>>
>>>> On 7/5/2015 5:10 PM, Richard Eckart de Castilho wrote:
>>>>> Built from SVN tag with empty .m2 using JDK 7 on OS X - OK
>>>>>
>>>>> Spot check for licenses and notices - OK
>>>>>
>>>>> Built Apache uimaFIT trunk against this RC - OK
>>>>>
>>>>> Built other software against this RC - OK
>>>>>
>>>>> Spot check signatures - look OK (still need to get into the web of
>> trust...)
>>>>>
>>>>> [X] +1 OK to release
>>>>>
>>>>>
>>>>> Link to "issues fixed" in RELEASE_NOTES.html of ZIP distribution does
>> not work. Shouldn't there be such a file in the ZIP? - Not critical, but
>> should be fixed in next release.
>>>>>
>>>>> Btw. we have many issues that were marked as "resolved" or "closed"
>> but that do not have an assignee:
>>>>>
>>>>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(EMPTY)
>>>>>
>>>>> I fixed the assignee on those issues that I had initially reported.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> -- Richard
>>>>>
>>>>> On 04.07.2015, at 20:49, Marshall Schor <ms...@schor.com> wrote:
>>>>>
>>>>>> signatures - OK
>>>>>>
>>>>>> Source compare with tag: OK
>>>>>>
>>>>>> Install into Eclipse Luna: OK; tested by running the Component
>> Descriptor Editor
>>>>>>
>>>>>> Build from sources - OK (needs Java 7, not 8 due to javadoc issues -
>> not a blocker)
>>>>>>
>>>>>> Issues Fixed - OK
>>>>>>
>>>>>> spot checked licenses and notices - OK
>>>>>>
>>>>>> from binary distribution, ran adjust example paths, and document
>> analyzer, and
>>>>>> Java results viewer (showing new Features view) - OK
>>>>>>
>>>>>> [X] +1 OK to release
>>>>>>
>>>>>> -Marshall Schor
>>>
>>
>>
Re: [VOTE] Release UIMA SDK 2.8.0 rc4
Posted by Burn Lewis <bu...@gmail.com>.
The release notes say no API changes, but the return type of
org.apache.uima.jcas.getAllIndexedFS has changed from FSIterator<TOP> to
FSIterator<FeatureStructure> which has produced a compile error in our code.
On Mon, Jul 6, 2015 at 3:57 PM, Marshall Schor <ms...@schor.com> wrote:
> thanks, again :-) .
>
> I remember that the lib folder jar names were debated 6-7 years ago. The
> debate
> centered more around whether or not to adopt the standard of how these
> jars are
> named in the Maven artifact repository.
> e.g.
> maven repo: uimaj-core-2.7.0.jar
> lib: uima-core.jar
>
> Not only is the "j" different, but the maven repo has the version appended.
>
> Also, https://issues.apache.org/jira/browse/UIMA-355 has some comments on
> renaming.
>
> You can find this discussion in the mail archives. For instance, search
> uima.markmail.org with the keywords:
> naming uima-core uima-355
>
> The bottom line for me sort of nets out to the following:
>
> 1) Renaming the Jars to follow the Maven names would make things more
> consistent
> 2) Renaming the Jars to follow the Maven names would somewhat impact our
> users
> (who might be hard-coding the jar name, which for now, doesn't change in
> the
> lib/ dir of the binary distribution).
>
> When I weight these two reasons, I feel it's more important not to impact
> our
> users, given the benefit is only one of some consistency.
> But if there were no impact to the users, I would be fine with changing
> this.
>
> -Marshall
>
>
>
> On 7/6/2015 12:52 PM, Richard Eckart de Castilho wrote:
> > Reason for the missing issuesFixed was that I was looking at a locally
> built
> > version (without -Papache-release) at that moment.
> >
> > Re-did spot check of licenses/notices against the ZIP you provided -
> still
> > looks all ok and the issuesFixed is there.
> >
> > So I maintain the +1.
> >
> > Btw. I think I pointed this out in the past: why not switch from the
> > "uima-XXX" naming to the proper "uimaj-XXX" naming in the lib folder?
> > The files identify themselves as "uimaj-XXX" in their NOTICE files.
> >
> > Cheers,
> >
> > -- Richard
> >
> > On 06.07.2015, at 16:50, Marshall Schor <ms...@schor.com> wrote:
> >
> >> Thanks for the quick vote!
> >>
> >> On the point about the link to "issues fixed" in RELEASE_NOTES.html of
> the zip
> >> distribution - I cannot reproduce this.
> >> I tried unzipping the uimaj-2.8.0-bin.zip, then opening
> RELEASE_NOTES.html, then
> >> clicking on the table-of-contents link " List of JIRA Issues Fixed in
> this
> >> Release", and then clicked on "issuesFixed/jira-report.hmtl" under the
> heading
> >> "Full list of JIRA Issues Fixed in this Release".
> >>
> >> I also tried the same thing unzipping the
> uimaj-2.8.0-source-release.zip. Both
> >> worked OK for me.
> >>
> >> Can you say more precisely what failed? The zips both included a
> directory
> >> "issuesFixed", and within that, the file "jira-report.html". (My test
> was on
> >> Windows).
> >>
> >> -Marshall
> >>
> >> On 7/5/2015 5:10 PM, Richard Eckart de Castilho wrote:
> >>> Built from SVN tag with empty .m2 using JDK 7 on OS X - OK
> >>>
> >>> Spot check for licenses and notices - OK
> >>>
> >>> Built Apache uimaFIT trunk against this RC - OK
> >>>
> >>> Built other software against this RC - OK
> >>>
> >>> Spot check signatures - look OK (still need to get into the web of
> trust...)
> >>>
> >>> [X] +1 OK to release
> >>>
> >>>
> >>> Link to "issues fixed" in RELEASE_NOTES.html of ZIP distribution does
> not work. Shouldn't there be such a file in the ZIP? - Not critical, but
> should be fixed in next release.
> >>>
> >>> Btw. we have many issues that were marked as "resolved" or "closed"
> but that do not have an assignee:
> >>>
> >>>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(EMPTY)
> >>>
> >>> I fixed the assignee on those issues that I had initially reported.
> >>>
> >>> Cheers,
> >>>
> >>> -- Richard
> >>>
> >>> On 04.07.2015, at 20:49, Marshall Schor <ms...@schor.com> wrote:
> >>>
> >>>> signatures - OK
> >>>>
> >>>> Source compare with tag: OK
> >>>>
> >>>> Install into Eclipse Luna: OK; tested by running the Component
> Descriptor Editor
> >>>>
> >>>> Build from sources - OK (needs Java 7, not 8 due to javadoc issues -
> not a blocker)
> >>>>
> >>>> Issues Fixed - OK
> >>>>
> >>>> spot checked licenses and notices - OK
> >>>>
> >>>> from binary distribution, ran adjust example paths, and document
> analyzer, and
> >>>> Java results viewer (showing new Features view) - OK
> >>>>
> >>>> [X] +1 OK to release
> >>>>
> >>>> -Marshall Schor
> >
>
>
Re: [VOTE] Release UIMA SDK 2.8.0 rc4
Posted by Marshall Schor <ms...@schor.com>.
thanks, again :-) .
I remember that the lib folder jar names were debated 6-7 years ago. The debate
centered more around whether or not to adopt the standard of how these jars are
named in the Maven artifact repository.
e.g.
maven repo: uimaj-core-2.7.0.jar
lib: uima-core.jar
Not only is the "j" different, but the maven repo has the version appended.
Also, https://issues.apache.org/jira/browse/UIMA-355 has some comments on renaming.
You can find this discussion in the mail archives. For instance, search
uima.markmail.org with the keywords:
naming uima-core uima-355
The bottom line for me sort of nets out to the following:
1) Renaming the Jars to follow the Maven names would make things more consistent
2) Renaming the Jars to follow the Maven names would somewhat impact our users
(who might be hard-coding the jar name, which for now, doesn't change in the
lib/ dir of the binary distribution).
When I weight these two reasons, I feel it's more important not to impact our
users, given the benefit is only one of some consistency.
But if there were no impact to the users, I would be fine with changing this.
-Marshall
On 7/6/2015 12:52 PM, Richard Eckart de Castilho wrote:
> Reason for the missing issuesFixed was that I was looking at a locally built
> version (without -Papache-release) at that moment.
>
> Re-did spot check of licenses/notices against the ZIP you provided - still
> looks all ok and the issuesFixed is there.
>
> So I maintain the +1.
>
> Btw. I think I pointed this out in the past: why not switch from the
> "uima-XXX" naming to the proper "uimaj-XXX" naming in the lib folder?
> The files identify themselves as "uimaj-XXX" in their NOTICE files.
>
> Cheers,
>
> -- Richard
>
> On 06.07.2015, at 16:50, Marshall Schor <ms...@schor.com> wrote:
>
>> Thanks for the quick vote!
>>
>> On the point about the link to "issues fixed" in RELEASE_NOTES.html of the zip
>> distribution - I cannot reproduce this.
>> I tried unzipping the uimaj-2.8.0-bin.zip, then opening RELEASE_NOTES.html, then
>> clicking on the table-of-contents link " List of JIRA Issues Fixed in this
>> Release", and then clicked on "issuesFixed/jira-report.hmtl" under the heading
>> "Full list of JIRA Issues Fixed in this Release".
>>
>> I also tried the same thing unzipping the uimaj-2.8.0-source-release.zip. Both
>> worked OK for me.
>>
>> Can you say more precisely what failed? The zips both included a directory
>> "issuesFixed", and within that, the file "jira-report.html". (My test was on
>> Windows).
>>
>> -Marshall
>>
>> On 7/5/2015 5:10 PM, Richard Eckart de Castilho wrote:
>>> Built from SVN tag with empty .m2 using JDK 7 on OS X - OK
>>>
>>> Spot check for licenses and notices - OK
>>>
>>> Built Apache uimaFIT trunk against this RC - OK
>>>
>>> Built other software against this RC - OK
>>>
>>> Spot check signatures - look OK (still need to get into the web of trust...)
>>>
>>> [X] +1 OK to release
>>>
>>>
>>> Link to "issues fixed" in RELEASE_NOTES.html of ZIP distribution does not work. Shouldn't there be such a file in the ZIP? - Not critical, but should be fixed in next release.
>>>
>>> Btw. we have many issues that were marked as "resolved" or "closed" but that do not have an assignee:
>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(EMPTY)
>>>
>>> I fixed the assignee on those issues that I had initially reported.
>>>
>>> Cheers,
>>>
>>> -- Richard
>>>
>>> On 04.07.2015, at 20:49, Marshall Schor <ms...@schor.com> wrote:
>>>
>>>> signatures - OK
>>>>
>>>> Source compare with tag: OK
>>>>
>>>> Install into Eclipse Luna: OK; tested by running the Component Descriptor Editor
>>>>
>>>> Build from sources - OK (needs Java 7, not 8 due to javadoc issues - not a blocker)
>>>>
>>>> Issues Fixed - OK
>>>>
>>>> spot checked licenses and notices - OK
>>>>
>>>> from binary distribution, ran adjust example paths, and document analyzer, and
>>>> Java results viewer (showing new Features view) - OK
>>>>
>>>> [X] +1 OK to release
>>>>
>>>> -Marshall Schor
>
Re: [VOTE] Release UIMA SDK 2.8.0 rc4
Posted by Richard Eckart de Castilho <re...@apache.org>.
Reason for the missing issuesFixed was that I was looking at a locally built
version (without -Papache-release) at that moment.
Re-did spot check of licenses/notices against the ZIP you provided - still
looks all ok and the issuesFixed is there.
So I maintain the +1.
Btw. I think I pointed this out in the past: why not switch from the
"uima-XXX" naming to the proper "uimaj-XXX" naming in the lib folder?
The files identify themselves as "uimaj-XXX" in their NOTICE files.
Cheers,
-- Richard
On 06.07.2015, at 16:50, Marshall Schor <ms...@schor.com> wrote:
> Thanks for the quick vote!
>
> On the point about the link to "issues fixed" in RELEASE_NOTES.html of the zip
> distribution - I cannot reproduce this.
> I tried unzipping the uimaj-2.8.0-bin.zip, then opening RELEASE_NOTES.html, then
> clicking on the table-of-contents link " List of JIRA Issues Fixed in this
> Release", and then clicked on "issuesFixed/jira-report.hmtl" under the heading
> "Full list of JIRA Issues Fixed in this Release".
>
> I also tried the same thing unzipping the uimaj-2.8.0-source-release.zip. Both
> worked OK for me.
>
> Can you say more precisely what failed? The zips both included a directory
> "issuesFixed", and within that, the file "jira-report.html". (My test was on
> Windows).
>
> -Marshall
>
> On 7/5/2015 5:10 PM, Richard Eckart de Castilho wrote:
>> Built from SVN tag with empty .m2 using JDK 7 on OS X - OK
>>
>> Spot check for licenses and notices - OK
>>
>> Built Apache uimaFIT trunk against this RC - OK
>>
>> Built other software against this RC - OK
>>
>> Spot check signatures - look OK (still need to get into the web of trust...)
>>
>> [X] +1 OK to release
>>
>>
>> Link to "issues fixed" in RELEASE_NOTES.html of ZIP distribution does not work. Shouldn't there be such a file in the ZIP? - Not critical, but should be fixed in next release.
>>
>> Btw. we have many issues that were marked as "resolved" or "closed" but that do not have an assignee:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(EMPTY)
>>
>> I fixed the assignee on those issues that I had initially reported.
>>
>> Cheers,
>>
>> -- Richard
>>
>> On 04.07.2015, at 20:49, Marshall Schor <ms...@schor.com> wrote:
>>
>>> signatures - OK
>>>
>>> Source compare with tag: OK
>>>
>>> Install into Eclipse Luna: OK; tested by running the Component Descriptor Editor
>>>
>>> Build from sources - OK (needs Java 7, not 8 due to javadoc issues - not a blocker)
>>>
>>> Issues Fixed - OK
>>>
>>> spot checked licenses and notices - OK
>>>
>>> from binary distribution, ran adjust example paths, and document analyzer, and
>>> Java results viewer (showing new Features view) - OK
>>>
>>> [X] +1 OK to release
>>>
>>> -Marshall Schor
>>
>
Re: [VOTE] Release UIMA SDK 2.8.0 rc4
Posted by Marshall Schor <ms...@schor.com>.
Thanks for the quick vote!
On the point about the link to "issues fixed" in RELEASE_NOTES.html of the zip
distribution - I cannot reproduce this.
I tried unzipping the uimaj-2.8.0-bin.zip, then opening RELEASE_NOTES.html, then
clicking on the table-of-contents link " List of JIRA Issues Fixed in this
Release", and then clicked on "issuesFixed/jira-report.hmtl" under the heading
"Full list of JIRA Issues Fixed in this Release".
I also tried the same thing unzipping the uimaj-2.8.0-source-release.zip. Both
worked OK for me.
Can you say more precisely what failed? The zips both included a directory
"issuesFixed", and within that, the file "jira-report.html". (My test was on
Windows).
-Marshall
On 7/5/2015 5:10 PM, Richard Eckart de Castilho wrote:
> Built from SVN tag with empty .m2 using JDK 7 on OS X - OK
>
> Spot check for licenses and notices - OK
>
> Built Apache uimaFIT trunk against this RC - OK
>
> Built other software against this RC - OK
>
> Spot check signatures - look OK (still need to get into the web of trust...)
>
> [X] +1 OK to release
>
>
> Link to "issues fixed" in RELEASE_NOTES.html of ZIP distribution does not work. Shouldn't there be such a file in the ZIP? - Not critical, but should be fixed in next release.
>
> Btw. we have many issues that were marked as "resolved" or "closed" but that do not have an assignee:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(EMPTY)
>
> I fixed the assignee on those issues that I had initially reported.
>
> Cheers,
>
> -- Richard
>
> On 04.07.2015, at 20:49, Marshall Schor <ms...@schor.com> wrote:
>
>> signatures - OK
>>
>> Source compare with tag: OK
>>
>> Install into Eclipse Luna: OK; tested by running the Component Descriptor Editor
>>
>> Build from sources - OK (needs Java 7, not 8 due to javadoc issues - not a blocker)
>>
>> Issues Fixed - OK
>>
>> spot checked licenses and notices - OK
>>
>> from binary distribution, ran adjust example paths, and document analyzer, and
>> Java results viewer (showing new Features view) - OK
>>
>> [X] +1 OK to release
>>
>> -Marshall Schor
>
Re: [VOTE] Release UIMA SDK 2.8.0 rc4
Posted by Richard Eckart de Castilho <re...@apache.org>.
Built from SVN tag with empty .m2 using JDK 7 on OS X - OK
Spot check for licenses and notices - OK
Built Apache uimaFIT trunk against this RC - OK
Built other software against this RC - OK
Spot check signatures - look OK (still need to get into the web of trust...)
[X] +1 OK to release
Link to "issues fixed" in RELEASE_NOTES.html of ZIP distribution does not work. Shouldn't there be such a file in the ZIP? - Not critical, but should be fixed in next release.
Btw. we have many issues that were marked as "resolved" or "closed" but that do not have an assignee:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(EMPTY)
I fixed the assignee on those issues that I had initially reported.
Cheers,
-- Richard
On 04.07.2015, at 20:49, Marshall Schor <ms...@schor.com> wrote:
> signatures - OK
>
> Source compare with tag: OK
>
> Install into Eclipse Luna: OK; tested by running the Component Descriptor Editor
>
> Build from sources - OK (needs Java 7, not 8 due to javadoc issues - not a blocker)
>
> Issues Fixed - OK
>
> spot checked licenses and notices - OK
>
> from binary distribution, ran adjust example paths, and document analyzer, and
> Java results viewer (showing new Features view) - OK
>
> [X] +1 OK to release
>
> -Marshall Schor
Re: [VOTE] Release UIMA SDK 2.8.0 rc4
Posted by Marshall Schor <ms...@schor.com>.
signatures - OK
Source compare with tag: OK
Install into Eclipse Luna: OK; tested by running the Component Descriptor Editor
Build from sources - OK (needs Java 7, not 8 due to javadoc issues - not a blocker)
Issues Fixed - OK
spot checked licenses and notices - OK
from binary distribution, ran adjust example paths, and document analyzer, and
Java results viewer (showing new Features view) - OK
[X] +1 OK to release
-Marshall Schor
[VOTE] [CANCEL] Release UIMA SDK 2.8.0 rc4
Posted by Marshall Schor <ms...@schor.com>.
Cancelling the vote based on the issue found by Burn regarding generics in
getAllIndexedFS.
-Marshall
On 7/4/2015 12:17 AM, Marshall Schor wrote:
> Hi,
>
> RC 4 is the same as rc3 except for this Jira and its fix:
> https://issues.apache.org/jira/browse/UIMA-4501
>
> Previous changes: updating the property to make the right issues-fixed, the copy
> iterator issue(s), and mainly other bug fixes, but includes two new things: one
> is the index flattening for sorted indexes, and the other is the improved Java
> Cas view that's part of the document analyzer.
>
> The list of changes in Jira:
>
> https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.8.0SDK%20AND%20project%20%3D%20UIMA
>
> The source and binary zip/tars and the Eclipse update site are staged to
> http://people.apache.org/~schor/uima-release-candidates/uimaj-2.8.0-rc4
> <http://people.apache.org/%7Eschor/uima-release-candidates/uimaj-2.8.0-rc4>
>
> The Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapacheuima-1059
>
> The SVN tags are here:
> http://svn.apache.org/repos/asf/uima/uimaj/tags/uimaj-2.8.0/
>
> and for the Eclipse Update Site:
> https://people.apache.org/~schor/uima-release-candidates/uimaj-2.8.0-rc4/eclipse-update-site/uimaj/
> <https://people.apache.org/%7Eschor/uima-release-candidates/uimaj-2.8.0-rc4/eclipse-update-site/uimaj/>
>
> See http://uima.apache.org/testing-builds.html for suggestions on how to test
> release candidates.
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> -Marshall
>
>