incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: [VOTE] Apache Drill 0.6.0-incubating release
Date Wed, 08 Oct 2014 19:52:35 GMT
+1 (binding)

I have downloaded the code, compiled and run the tests.

I also checked all checksums, and verified the signatures.  I also verified
that the signing key was signed by people I trust (and indeed, by me as
well) and correctly propagated to the gpg key servers.

I also reviewed in both the source and binary that the various notices,
licenses and dependency lists appear to be correct.  The license files also
appear to be correct and include the correct attributions.  I have
previously checked that the list of dependencies and attributions was both
correct and complete and since these are generated automatically, I did not
specifically check them again.  Moreover, the dependencies have not changed
so this gives even higher confidence in this assessment.

It should be noted that Drill as a project has been able to produce several
high quality releases in a row with different release managers.  Moreover,
Drill has invested in documentation to help train release managers to help
grow the community.



On Tue, Oct 7, 2014 at 8:41 AM, jan i <jani@apache.org> wrote:

> Hi.
>
> I have had a look at your release and it looks good, I could not find any
> formal errors.
>
> But I took a closer look at the release vote thread, because a failing unit
> test is a serious bad quality signal for me.
>
> Whenever I test new software, I download it, build it, then run all  test
> cases to secure I got it build correctly, where I assume I have made
> something wrong if a test case fails.
>
> Apache is known for quality software and I think we all want to keep that
> image. I am sure the project does not take quality lightly, but the
> attitude "can be fixed later" especially with unit tests is to me not a
> good policy.
>
> If the software only runs with 1.7 and not higher, then why not make a
> simple startup version check, then there would be no problem (of course its
> even better to solve the problem). I just wonder how this error will affect
> people using the project.
>
> It seems (from the vote thread) you already have solved the problem, but
> dont want to wait for a respin, can you please at least explain why the
> project is under such a time constraint, that 72 hours is too long to wait
> to make good quality.
>
> I wanted to give the release a -1 but decided to give
>
> -0 binding.
>
> in the hope the PMC will go for quality and voluntary respin the release.
>
> rgds
> jan i
>
>
>
> On 7 October 2014 07:09, Steven Phillips <sphillips@maprtech.com> wrote:
>
> > In case there is any confusion, the first email sent out in this thread
> had
> > the wrong vote count. The second one has the correct count:
> >
> > +9 binding
> > +3 non-binding
> >
> > I should also mention there was one -0 (binding). This was due to unit
> test
> > failures when using java 1.8. Jiras were filed, and the fix will be
> > included in the next release, not this one.
> >
> > On Sun, Oct 5, 2014 at 11:14 AM, Steven Phillips <smp@apache.org> wrote:
> >
> > > I would like to present the Apache Drill 0.6.0-incubating release to
> > > the general incubator list for a vote.  This set of artifacts have
> passed
> > > our drill-dev vote and incorporate a number of improvements with over
> 30
> > > JIRAs closed in the last month.
> > >
> > > The vote thread can be found here:
> >
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E
> > >
> > > The vote passed with:
> > > +9 binding
> > > +3 non-binding
> > >
> > > You can find the artifacts for the release at this location:
> > http://people.apache.org/~smp/apache-drill-0.6.0.rc0/
> > >
> > > I look forward to your feedback.
> > >
> > > Thanks,
> > > Steven
> > >
> > >
> >
> >
> > --
> >  Steven Phillips
> >  Software Engineer
> >
> >  mapr.com
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message