Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Drill >> mail # dev >> RC3 Vote: Third time's the charm?

Copy link to this message
Re: RC3 Vote: Third time's the charm?
On Sun, Sep 08, 2013 at 01:17:45PM -0700, Ted Dunning wrote:
> I have asked Grant and Isabel to take a peek and help us get a more
> complete view of what is needed as well.  I may ask somebody else from the
> incubator crew to give us a hand, especially if Grant and Isabel are tied
> up.
>From a first glance at the release (some points already mentioned by
Ted and Grant):

As mentioned earlier there are many source files with missing license
headers - RAT is a good way for finding those. You might want to check
out the Maven Enforcer Plugin or checkstyle for missing license headers,
during each build. In addition there's a maven plugin called
maven-license-plugin that can automatically add a pre-defined header to
all source files at build time (not too sure how well maintained that
is right now though).

There's some detailed explanation online which files require license
header: <http://www.apache.org/legal/src-headers.html> or the incubator
version over at

As for the licenses of software the project depends on: Over at Mahout we
list which packages we depend on in the NOTICE file. This can be
automated via the maven-remote-resources plugin. Note: This information
is in the NOTICE file even for the source only release. Maven itself seems
to be doing this a little different, listing only brief summaries of the
dependencies in the NOTICE file and a detailed list in a file named

It looks like the release naming is not quite right - it should contain
"incubating" somewhere in the version. See "Naming" section of the incubator
release management best practices.

Also the release should contain the incubator disclaimer e.g. in the README,
Release notes or similar - see "The incubator disclaimer" in the above
release management best practices.

According to <https://www.apache.org/dev/release-signing> there's also
a requirement for an MD5 checksum and a should for a SHA checksum. I'm not
quite sure though how this plays together with releasing to the Apache
nexus with Maven. You might want to dig deeper there:

When verifying the signature for the source artifact I noticed that the names
of the signature and the actual artifact do not quite match. Having them
exactly the same exact for the ".asc" suffix makes verification easier/
automatic. The maven gpg plugin that is configured in the Apache parent pom
should do this automatically though. How were the signatures generated?

One minor nitpick - you might want to make sure that over time the drill
release managers get their gpg keys signed by other Apache people.
So overall -1 from my side.