aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Chu-Carroll <mchucarr...@apache.org>
Subject Re: [VOTE] Release Apache Aurora 0.5.0 (incubating) RC0
Date Wed, 14 May 2014 12:04:11 GMT
Henry: yes, if it doesn't work, I'm definitely -1.

   -Mark


On Tue, May 13, 2014 at 7:32 PM, Henry Saputra <henry.saputra@gmail.com>wrote:

> Hi Mark,
>
> Does this mean you are -1 of the release candidate?
>
> - Henry
>
> On Tue, May 6, 2014 at 12:10 PM, Mark Chu-Carroll
> <mchucarroll@apache.org> wrote:
> > Just tried again, and get the same error. I'm attaching transcripts of
> the
> > "vagrant up", and the run of the test script.
> >
> >
> >
> > On Tue, May 6, 2014 at 11:41 AM, Mark Chu-Carroll <
> mchucarroll@apache.org>
> > wrote:
> >>
> >> Grabbing the RC, downloading it, running vagrant up, and then trying to
> >> just run the end to end test fails, because the aurora client isn't
> found in
> >> the vagrant image:
> >>
> >> + vagrant ssh devcluster -c 'aurora killall
> >> devcluster/vagrant/test/flask_example'
> >> bash: line 2: aurora: command not found
> >>
> >>
> >> On Mon, May 5, 2014 at 9:28 PM, Justin Mclean <justin@classsoftware.com
> >
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> As an IPMC/previous shepherd thought I give my feedback.
> >>>
> >>> Signatures and hashes all good
> >>> DISCLAIMER correct
> >>> Filename contains "incubating"
> >>> NOTICE and LICENCE good (checked all 3rd party bit of code and they all
> >>> seem to be there)
> >>> Not all files have correct headers - may or may not be OK
> >>> There's a few binaries in the release
> >>> Can compile from source
> >>> Test pass
> >>>
> >>> From a quick look there are python, CSS, JS, JSON and HMTL template
> (tpl)
> >>> files that are misisng headers. Some are 3rd party so may not be an
> issue
> >>> but the ones in src/main/resources/org/apache/aurora/scheduler may be?
> Given
> >>> the large number of files (207) it's a little hard to easily review
> this.
> >>> Has rat been run on the release?
> >>>
> >>> Binary files in release - some of these may be OK
> >>> /3rdparty/javascript/bower_components/angular/angular.min.js.gzip
> >>> /gradle/wrapper/gradle-wrapper.jar
> >>> /src/test/resources/org/apache/aurora/scheduler/app/AuroraTestKeyStore
> >>>
> /src/resources/org/apache/thermos/root/checkpoints/failure/coordinator.*
> >>>
> >>> Re the gradle wrapper I was able to use gradle to compile without it so
> >>> it may not actually be required in the source release?
> >>>
> >>> As it was not mentioned directly in the README etc I was unaware that
> you
> >>> should use gradlew command instead. I saw later that it is mentioned in
> >>> docs/developing-aurora-scheduler.md.
> >>>
> >>> A few (very) minor things:
> >>> - Release file doesn't have apache in it's name, while not required it
> >>> may give extra legal protection [1]
> >>> - KEYS are usually outside release package
> >>> - Not sure if this is possible, as i'm not familiar with gradle,  but
> you
> >>> may want to consider a source and binary release with the binary
> having the
> >>> gradle jar?
> >>> - BUILD is usually named BUILDING or the build information put in
> README.
> >>> - I notice the .asc file has .md5 and .sha hashes of it in the RC
> >>> directory. There are probably not required.
> >>>
> >>> I'm sure you know your own project better that me, so if I've mentioned
> >>> something that already been discussed or I've misunderstood something I
> >>> apologise in advance. The fact I was able to take the source package
> and
> >>> compile it will minimal effort certainly indicates to me that it's
> release
> >>> ready.
> >>>
> >>> Thanks,
> >>> Justin
> >>>
> >>> 1.
> >>>
> http://incubator.apache.org/guides/releasemanagement.html#best-practice
> >>
> >>
> >
>

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