[VOTE] Release UIMA-DUCC 1.0.0 RC4

[Jaroslaw Cwiklik <ui...@gmail.com>]

Hi,

the fourth release candidate of the sandbox project Apache UIMA DUCC v1.0.0
is ready for voting.

Issues fixed in RC4:

1) Fixed NOTICE files
2) Modified README and RELEASE_NOTES
3) Changed location of DUCC docs
4) SM fails a job if its service dependencies are only whitespace
5) Updates to sampleapps to be consistent with recent build changes
6) Generate HTML for installation guide as well as PDF

DUCC stands for Distributed UIMA Cluster Computing. DUCC is a cluster
management system providing tooling, management, and scheduling facilities
to automate the scale-out of applications written to the UIMA framework.
Core UIMA provides a generalized framework for applications that process
unstructured information such as human language, but does not provide a
scale-out mechanism. UIMA-AS provides a scale-out mechanism to distribute
UIMA pipelines over a cluster of computing resources, but does not provide
job or cluster management of the resources. DUCC defines a formal job model
that closely maps to a standard UIMA pipeline. Around this job model DUCC
provides cluster management services to automate the scale-out of UIMA
pipelines over computing clusters.

The Maven artifacts are here:
http://repository.apache.org/content/repositories/orgapacheuima-015/org/apache/uima/<https://repository.apache.org/content/repositories/orgapacheuima-015/org/apache/uima/>

The source and binary zip/tars are here:
http://people.apache.org/~cwiklik/releases/uima-ducc/1.0.0/RC4/

The SVN Tag Checkout:
http://svn.apache.org/repos/asf/uima/sandbox/uima-ducc/tags/uima-ducc-1.0.0/

See: http://uima.apache.org/testing-builds.html for instructions how to
test release candidate.

Please vote on release:

[ ] +1 OK to release
[ ]  0 Don't care
[ ] -1 Not OK to release, because ...

Re: [VOTE] Release UIMA-DUCC 1.0.0 RC4

[Marshall Schor <ms...@schor.com>]

The way "newly added" files are supposed to get the svn:eol-style property is
that the machines where you do your svn commit from, are supposed to have SVN
configured to do this; see http://uima.apache.org/one-time-setup.html#svn-setup

The source-release.zip, having been built (I believe) on a linux machine, you
might think ought to have just the unix-style line endings.  I checked, and
found a few files here that have windows style.  Some of these are generated:
   issues-fixed...

but others seem to be checked in with windows line endings and no eol-style
property; some examples:
  org.apache.uima.ducc.agent.launcher.CGroupsManager.java
  ...common.agent.metrics.swap.  (4 java files)
 
-Marshall

Re: [VOTE] Release UIMA-DUCC 1.0.0 RC4

[Marshall Schor <ms...@schor.com>]

This is somehow related to a late commit to trunk done here:

http://svn.apache.org/viewvc/uima/sandbox/uima-ducc/trunk/uima-ducc-duccdocs/src/site/tex/duccbook/part3/ducc-applications.tex?r1=1556062&r2=1556274

The source.zip picked up the "old" value, while the tag got the new one.

This can't happen, except as follows:

1) the release:prepare builds from the copy in the checkout on disk (which could
be missing a late-arriving update).
2) the release:prepare therefore builds in /target a version of source-release
without the late-arriving update.
3) the release:prepare "tags" the source, but this is done by telling SVN to
'copy' the trunk to the tag; data is not transmitted from the checkout to the
tag.  This means, the tag has the late-arriving update).
4) the release:perform checkouts the tag into .../target/checkout, and builds
that.  This creates new artifacts in  .../target/checkout/target, including a
new source-release.zip.  This will match the svn tag.

The error occurred when the source-release.zip was posted to p.a.o for
examination: it was uploaded (manually) from
.../target/uima-ducc-1.0.0-source-release.zip, instead of
.../target/checkout/target/uima-ducc-1.0.0-source-release.zip.

This uploaded the version of source-release which was missing the late-arriving
change.

So, the moral of this story is 2-fold: don't change the trunk while someone's
doing releasing :-), and when uploading release candidate artifacts, be sure to
pick them from .../target/checkout/target/... not .../target.

I'll add a note about this to our web-site pages release and checklist-release.

-Marshall
On 1/8/2014 3:03 PM, Marshall Schor wrote:
> After correcting for line ending differences, I find a few places the SVN tag
> and the source zip don't compare:
>
> svn tag: ducc-applications.tex: line 318 -
>
>    MyAppDir=$PWD \
>    MyInputDir=$PWD/Books \
>    MyOutputDir=$PWD/Books.processed \
>
> source zip:
>
>    MyAppDir=. \
>    MyInputDir=$MyAppDir/Books \
>    MyOutputDir=$MyAppDir/Books.processed \
>
> plus 2 more instances in this file.
>
> It would seem impossible, if normal release / build approaches were done, for
> these to differ.  Can anyone explain how this happened?
>
> -Marshall
>

Re: [VOTE] Release UIMA-DUCC 1.0.0 RC4

[Jaroslaw Cwiklik <ui...@gmail.com>]

I remember doing svn update to pickup Jim's changes before building. I
suspect that some time passed before I started RC4 build and right before
someone has checked in the new code. Still a mystery how the
release:prepare would have allowed this inconsistency to happen.


On Wed, Jan 8, 2014 at 3:03 PM, Marshall Schor <ms...@schor.com> wrote:

> After correcting for line ending differences, I find a few places the SVN
> tag
> and the source zip don't compare:
>
> svn tag: ducc-applications.tex: line 318 -
>
>    MyAppDir=$PWD \
>    MyInputDir=$PWD/Books \
>    MyOutputDir=$PWD/Books.processed \
>
> source zip:
>
>    MyAppDir=. \
>    MyInputDir=$MyAppDir/Books \
>    MyOutputDir=$MyAppDir/Books.processed \
>
> plus 2 more instances in this file.
>
> It would seem impossible, if normal release / build approaches were done,
> for
> these to differ.  Can anyone explain how this happened?
>
> -Marshall
>

Re: [VOTE] Release UIMA-DUCC 1.0.0 RC4

[Marshall Schor <ms...@schor.com>]

After correcting for line ending differences, I find a few places the SVN tag
and the source zip don't compare:

svn tag: ducc-applications.tex: line 318 -

   MyAppDir=$PWD \
   MyInputDir=$PWD/Books \
   MyOutputDir=$PWD/Books.processed \

source zip:

   MyAppDir=. \
   MyInputDir=$MyAppDir/Books \
   MyOutputDir=$MyAppDir/Books.processed \

plus 2 more instances in this file.

It would seem impossible, if normal release / build approaches were done, for
these to differ.  Can anyone explain how this happened?

-Marshall

Re: [VOTE] Release UIMA-DUCC 1.0.0 RC4

[Marshall Schor <ms...@schor.com>]

The source files for DUCC are not consistent with respect to the svn:eol-style
properties.  Many of them have this set to "native", many of them do not.

The result is that if you do an svn checkout on Windows vs some other platforms,
you get a mix of line endings style.

While this is not a show-stopper, it does make it difficult to compare the svn
tag checkout with the source-release.zip.

I'm using Eclipse "compare" to do the compare, and even if I set "ignore white
space", it still makes files which only differ in line-endings show up in the
list (although for each file, it correctly shows no differences).

-Marshall

Re: [VOTE] Release UIMA-DUCC 1.0.0 RC4

[Marshall Schor <ms...@schor.com>]

The binary LICENSE file has the first letter in copyright missing for
DataTables, it says "opyright"...

The binary NOTICE file has boiler plate from UIMA-AS included: it says "portions
of UIMA-AS were originally....".  This may be intentional, since you are
packaging UIMA-AS with this.   Should you have one for DUCC too?

The Release notes has a link for the issues list.  On my chrome browser this
link shows not the list, but just one issue.
I think it would be better to do a more reliable link, such as:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%221.0-Ducc%22%20ORDER%20BY%20key%20ASC


Some of the notices in uima-as are not in the NOTICES file - eg. ibatis.  Is
this because not all of uima-as is being included?

-Marshall

Re: [VOTE] Release UIMA-DUCC 1.0.0 RC4

[Marshall Schor <ms...@schor.com>]

The issuesFixed report is messed up.  There are multiple issues.

I realize that this is "moot" because the report isn't referenced from things
like the Release Notes, but here's what my investigations have turned up.

The first thing is that the jira report is being run twice.  This is because the
uima-ducc pom calls out an execution of it under the execution ID
ducc-jira-report.  Because this id is different from the parent pom one for this
(which is default-cli -- so named so that it can be run from the command line
[following maven conventions]), this plugin spec doesn't "override" the one in
the parent pom, and in fact, the report runs twice.   (If you named it the same
execution ID, it would override / augment the parent pom configuration of the
same execution ID.)

The non-overridden one ends up running the report for the build/parent-pom
project's issues, and that's what shows up in the result of the build.

So, to fix this, I would recommend removing the maven-changes-plugin from the
uima-ducc pom, and having the uima-ducc parent pom's parent be the (now
released) version 8 (which has the right level of the maven-changes-plugin).

To specify which "version" the maven-changes-plugin should run against you
define a property.  This property is currently defined in the uima-ducc-parent
pom; but it's not a "factored" thing, not shared; it's only used by the
uima-ducc project, so I would suggest moving it to that project. 

The name for this property (used by the common uima-wide parent pom) is
jiraVersion.  I note that the property used in the uima-ducc-parent is spelled
differently:  jira.version

Assuming you are going to inherit the configuration of this plugin from the
uima-wide parent pom (v 8)  (recommend), then you will need to spell the
property jiraVersion instead.

Finally, by running in debug mode, I found that although we request 1000 (max
number of Jiras) be fetched, that number is reduced to just 100 by a limiter in
the Apache Jira configuration, so even when everything is configured correctly,
the Jira report is truncated to just 100 entries.  Normally, this is enough
(between releases). 

It might be best to "turn off" the jira report generation altogether for this
release, because we're not providing this for the first release.  The easy way
to do this is to add a stanza to the uima-ducc POM in the <build> <plugins>
section which specifies for the <id>default-cli</id> an empty phase :
<phase></phase>

...
  <plugin>
     <artifactId>maven-changes-plugin</artifactId>
     <executions>
         <execution>
             <id>default-cli</id>
             <phase/>
         </execution>
     </executions>
  </plugin>

If we find we're having more than 100 Jira's per release, let's ask INFRA to up
the limit on Apache's JIRA installation.

-Marshall