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?
I understand there are still outstanding issues with the licenses and
disclaimers, but just wanted to report a successful build over here. +1
from me once those issues are sorted out.

-Jason
On Mon, Sep 9, 2013 at 11:11 AM, Jacques Nadeau <[EMAIL PROTECTED]> wrote:

> Grant, Isabel and Ted,
>
> Thanks so much for the feedback.  I've filed DRILL- 221-225 to be addressed
> prior to release.
>
> Grant Questions:
> * You're compile failure was due to a lack of the protobuf 2.5.x compiler
> being installed on your build system.  I've filed a JIRA to include this
> requirement in the README.
> * per your question about versioning, the idea behind the milestone
> versioning was along the following, all working towards a 1.0.0 release:
> 3-7 milestone releases (we're currently at milestone 1), 1-2 beta releases,
> GA.
>
> Isabel Questions:
> * The next release candidate I post will ensure that the version number
> includes 'incubating'.
> * How were keys signed: via the standard Apache parent pom process.
> * I'll work with Ted to get my key signed.
>
> Please let me know if you think I accurately captured your concerns about
> the source release in the JIRAs.  We'll drop the binary release for this
> first release and catch it on the next one.
>
> thanks,
> Jacques
>
>
>
>
>
>
>
>
>
> On Mon, Sep 9, 2013 at 7:33 AM, Isabel Drost-Fromm <[EMAIL PROTECTED]
> >wrote:
>
> > 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
> > <http://incubator.apache.org/guides/releasemanagement.html#best-practice
> >
> >
> > 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
> > DEPENDENCIES.
> >
> > 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:
> > <http://www.apache.org/dev/publishing-maven-artifacts.html>
> >
> > 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/