[DISCUSS] Release Apache AsterixDB 0.8.7-incubating (RC3)

[Till Westmann <ti...@apache.org>]

Would it also be an option to
a) release the current release in source-only form,
b) not advertise/distribute the binaries for now, and
c) fix this for the next release?

Right now we have zero AsterixDB releases at the ASF and that way
we could have one that people have to build on their own (which is
the usual way at the ASF and no rocket science for any developer).
Also, I think that individual developer can still build a binary and
give it to someone for testing, it’s just not an ASF artifact at
that point.

Thoughts/Concerns?

Cheers,
Till


On 7 Oct 2015, at 15:49, Ian Maxon wrote:

> I see, thank you for the very detailed analysis Ate. I think we will 
> have
> to fix all of the binary assemblies to conform.  What's in Maven is
> important, as well as the bundled zips and such. Our usual method of
> distribution to end-users is via those bundled zips, rather than 
> source. In
> fact we actually had to add the source assembly specifically for 
> voting,
> typically developers or folks who need special patches simply check 
> out
> from git.
> More info/updates to come as I dig into how to coax maven into doing 
> this
> nicely...
>
> Thanks again,
> -Ian
>
> On Wed, Oct 7, 2015 at 3:24 PM, Ate Douma <at...@douma.nu> wrote:
>
>> Hi team,
>>
>> I either can +1 or -1 this release candidate, depending on if the 
>> staged
>> maven repository provided artifacts are also intended to be 
>> distributed...
>>
>> For just the source release (like for the Hyracks release), I think 
>> it is
>> good to go, so +1 for that.
>>
>> But for the binary artifacts in the Maven repo, it is definitely a 
>> -1.
>>
>> So either you'll drop/skip releasing to the Maven repo for this time, 
>> and
>> then you might be good (pending possible feedback from others), or 
>> this
>> vote better be cancelled and prepare for a lot of work to get this 
>> fixed
>> first...
>>
>> As I already mentioned on the Hyracks release candidate: LICENSE, 
>> NOTICE
>> and DISCLAIMER requirements apply to all released/distributed 
>> artifacts.
>> As such, all the build artifacts in the Maven repository also have to
>> contain and provide these...
>> Please check again the requirements for binary (re)distributions 
>> here:
>>
>> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
>> http://www.apache.org/dev/licensing-howto.html#deps-of-deps
>> http://www.apache.org/dev/licensing-howto.html#binary
>>
>> And in general everything on whole page.
>>
>> Some of the Maven repo jars already do have the 'verbatim' Apache 
>> LICENSE
>> and NOTICE files, but none provide the Incubator DISCLAIMER, which in
>> addition to the above rules also is required for every distribution 
>> from
>> the Incubator.
>>
>> And some others jars don't even bundle a LICENSE and NOTICE file like
>> asterix-common-0.8.7-incubating.jar (there are possibly more, I 
>> didn't
>> check each and every one).
>>
>> And besides this, aggregating distributions like all .zip|.tar etc. 
>> files
>> contain none of these files. Including module -source-release.zip 
>> files
>> like asterix-events-0.8.7-incubating-source-release.zip and the 
>> -demo.zip
>> files.
>>
>> All of these artifacts when released/distributed have to comply to 
>> the
>> above rules.
>> Which most definitely isn't a trivial task to comply with and 
>> typically
>> takes several iterations to get right... Painful yes, but necessary.
>> Once setup and configured properly though, thereafter it usually 
>> doesn't
>> require a lot of work to keep it up to date.
>>
>> But getting it right the first time will.
>> Just saying so that you'll all be aware this isn't something likely
>> fixable in a few minutes or even hours...
>>
>> Two important things to keep in mind:
>> - LICENSE and NOTICE files must be tailored specifically to the
>> distribution containing them, providing attribution to what the
>> distribution contains, but nothing more.
>> For example 3rd party embedded sources like JQuery require license
>> attribution, but NOT in artifacts NOT embedding them.
>> So the asterix-app should indeed mention this in the LICENSE file in 
>> its
>> jar AND -binary-assembly.zip, but for example the asterix-algebra jar
>> should NOT.
>> - Distributions bundling other distributions must aggregate possible
>> LICENSE and NOTICE attributions of those other distributions within 
>> their
>> main LICENSE and NOTICE file.
>> So for example, the LICENSE and NOTICE files in the asterix-app
>> binary-assembly.zip must aggregate those from the bundled/embedded
>> asterix-app *jar*.
>> And further more, as the binary-assembly.zip bundles many other,
>> including 3rd party, jars, their LICENSE and/or NOTICE attributions 
>> needs
>> to be aggregated as well (when needed, which depends on the 
>> particular
>> LICENSE and/or NOTICE). Including possible other licenses applicable 
>> to
>> those bundled jars (or whatever bundled bits).
>> And for aggregates of aggregates, like the asterix-installer
>> binary-assembly.zip, this has to be done 'transitively'. Yeah, a lot 
>> of
>> work indeed.
>>
>> I also like to refer back to the [DISCUSS] mail I send earlier on the
>> Hyracks release candidate, where I already indicated this to become
>> critical when releasing binary artifacts.
>> And to a few suggestions I gave then like configuring the
>> apache-incubator-disclaimer-resource-bundle to ensure the DISCLAIMER 
>> file
>> will automatically added to all generated jars (but not in assembled
>> artifacts).
>> And to leverage automatic *appending* specific LICENSE/NOTICE file
>> fragments for specific modules which embed 3rd party resources, via
>> src/main/appended-resources/META-INF/LICENSE and/or ./NOTICE files.
>>
>> I'm happy to try help out if this raises questions (and I expect it 
>> will),
>> but that'll be more practical to do case by case.
>> Trying to write down such 'guidelines' generically typically just 
>> leads to
>> more confusion :)
>>
>> Kind regards,
>> Ate
>>
>>
>> On 2015-10-05 22:16, Ian Maxon wrote:
>>
>>> Hi everyone,
>>>
>>> Please verify and vote on the first full Apache AsterixDB release!
>>> This candidate addresses some of the differences that were noticed
>>> between the tagged commit in git and the source packaging.
>>>
>>> The tag to be voted on is
>>>
>>> asterix-0.8.7-incubating
>>> commit : d2e1e89cfdf39e2b772dff2600913bb79644a380
>>> link:
>>> https://git-wip-us.apache.org/repos/asf?p=incubator-asterixdb.git;a=tag;h=refs/tags/asterix-0.8.7-incubating
>>>
>>> The artifacts, md5s, and signatures are at:
>>>
>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip
>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.asc
>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.md5
>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.sha1
>>>
>>> MD5: 7330e6d6c2dd691ae3ab6a641e4d5344
>>> SHA1: bf0b4a2ceaa26bcf1fcda33fee1ba227e31a88ba
>>>
>>> Additionally, a staged maven repository is available at:
>>> https://repository.apache.org/content/repositories/orgapacheasterix-1014/
>>>
>>> The KEYS file containing the PGP keys used to sign the release can 
>>> be
>>> found at
>>>
>>> https://dist.apache.org/repos/dist/release/incubator/asterixdb/KEYS
>>>
>>> RAT was executed as part of Maven via the RAT maven plugin, as well 
>>> as
>>> manually, but it
>>> excludes the following paths:
>>>
>>> .*\.adm
>>> .*\.aql
>>> .*\.cleaned
>>> .*\.csv
>>> .*\.csv.cr
>>> .*\.csv.crlf
>>> .*\.csv.lf
>>> .*\.ddl
>>> .*\.dot
>>> .*\.hcli
>>> .*\.iml
>>> .*\.json
>>> .*\.out
>>> .*\.plan
>>> .*\.ps
>>> .*\.scm
>>> .*\.tbl
>>> .*\.tbl\.big
>>> .*\.tsv
>>> .*\.txt
>>> .*large_text
>>> .*part-00000
>>> .*part-00001
>>>
>>> .*\.goutputstream-YQMB2V
>>> .*02-fuzzy-select
>>> .*LockRequestFile
>>> .*hosts
>>> .*id_rsa
>>> .*known_hosts
>>>
>>> .*bottle.py
>>> .*geostats.js
>>> .*jquery.autosize-min.js
>>> .*jquery.min.js
>>> .*rainbowvis.js
>>> .*smoothie.js
>>>
>>>
>>> These files either are either data for tests, procedurally 
>>> generated,
>>> or source files which come without a header mentioning their 
>>> license,
>>> but have an explicit reference in the LICENSE file.
>>>
>>> The complete RAT report is available at:
>>>
>>> https://gist.githubusercontent.com/westmann/b6ed4b25bea44adcd526/raw/be93ff0c1d13c2ce7c88a2b713ace130b5e7ef5f/gistfile1.txt
>>>
>>> The vote is open for 72 hours, or until the necessary number of 
>>> votes
>>> (3 +1) has been reached.
>>>
>>> Please vote
>>> [ ] +1 release this package as Apache AsterixDB 0.8.7-incubating
>>> [ ] 0 No strong feeling either way
>>> [ ] -1 do not release this package because ...
>>>
>>> Thanks!
>>> -Ian
>>>
>>>
>>

Re: [DISCUSS] Release Apache AsterixDB 0.8.7-incubating (RC3)

[Chris Hillery <ch...@hillery.land>]

Yes, I think we shouldn't expect apache.org to provide the download. I was
thinking we'd put it up for download in the same location as 0.8.6 was in.

Ceej
aka Chris Hillery
On Oct 8, 2015 1:56 PM, "Till Westmann" <ti...@apache.org> wrote:

> I think that the answer is “it depends”.
> It should be clear that the download is not an ASF artifact.
> If we provide that artifact from an apache.org address that’s more
> difficult to communicate than if we provide it e.g. from a uci.edu
> address.
>
> Who are the end-users that download today?
> Are they mostly students/researchers or is the audience wider than that?
>
> Thanks,
> Till
>
> On 8 Oct 2015, at 13:48, Chris Hillery wrote:
>
> Could we continue to provide those binary artifacts as "unofficial"
>> releases via our own website?
>>
>> Ceej
>> aka Chris Hillery
>> On Oct 8, 2015 1:40 PM, "Ian Maxon" <im...@uci.edu> wrote:
>>
>> Hm, alright, if that's something that seems valuable, then I'm OK with it.
>>> I suppose my eyes were set on getting the asterix-installer and
>>> asterix-yarn packagings out, since that's usually what end-users are
>>> downloading first. It is true that this has taken a lot longer than I
>>> think
>>> anyone would've liked.
>>>
>>> -Ian
>>>
>>> On Thu, Oct 8, 2015 at 1:25 PM, Chris Hillery <ch...@hillery.land>
>>> wrote:
>>>
>>> That sounds like a reasonable idea to me. If Ate is right that this
>>>>
>>> usually
>>>
>>>> takes several releases to get correct, it could be a really long time
>>>> before we have binaries fully ready to go. This release has already
>>>> taken
>>>> months longer than expected; let's have a source-only release for now so
>>>>
>>> we
>>>
>>>> can continue moving forward.
>>>>
>>>> Ceej
>>>> aka Chris Hillery
>>>> On Oct 8, 2015 1:15 PM, "Till Westmann" <ti...@apache.org> wrote:
>>>>
>>>> Would it also be an option to
>>>>> a) release the current release in source-only form,
>>>>> b) not advertise/distribute the binaries for now, and
>>>>> c) fix this for the next release?
>>>>>
>>>>> Right now we have zero AsterixDB releases at the ASF and that way
>>>>> we could have one that people have to build on their own (which is
>>>>> the usual way at the ASF and no rocket science for any developer).
>>>>> Also, I think that individual developer can still build a binary and
>>>>> give it to someone for testing, it’s just not an ASF artifact at
>>>>> that point.
>>>>>
>>>>> Thoughts/Concerns?
>>>>>
>>>>> Cheers,
>>>>> Till
>>>>>
>>>>>
>>>>> On 7 Oct 2015, at 15:49, Ian Maxon wrote:
>>>>>
>>>>> I see, thank you for the very detailed analysis Ate. I think we will
>>>>>
>>>> have
>>>
>>>> to fix all of the binary assemblies to conform.  What's in Maven is
>>>>>> important, as well as the bundled zips and such. Our usual method of
>>>>>> distribution to end-users is via those bundled zips, rather than
>>>>>>
>>>>> source.
>>>
>>>> In
>>>>>> fact we actually had to add the source assembly specifically for
>>>>>>
>>>>> voting,
>>>
>>>> typically developers or folks who need special patches simply check
>>>>>>
>>>>> out
>>>
>>>> from git.
>>>>>> More info/updates to come as I dig into how to coax maven into doing
>>>>>>
>>>>> this
>>>>
>>>>> nicely...
>>>>>>
>>>>>> Thanks again,
>>>>>> -Ian
>>>>>>
>>>>>> On Wed, Oct 7, 2015 at 3:24 PM, Ate Douma <at...@douma.nu> wrote:
>>>>>>
>>>>>> Hi team,
>>>>>>
>>>>>>>
>>>>>>> I either can +1 or -1 this release candidate, depending on if the
>>>>>>>
>>>>>> staged
>>>>
>>>>> maven repository provided artifacts are also intended to be
>>>>>>> distributed...
>>>>>>>
>>>>>>> For just the source release (like for the Hyracks release), I think
>>>>>>>
>>>>>> it
>>>
>>>> is
>>>>
>>>>> good to go, so +1 for that.
>>>>>>>
>>>>>>> But for the binary artifacts in the Maven repo, it is definitely a
>>>>>>>
>>>>>> -1.
>>>
>>>>
>>>>>>> So either you'll drop/skip releasing to the Maven repo for this time,
>>>>>>>
>>>>>> and
>>>>
>>>>> then you might be good (pending possible feedback from others), or
>>>>>>>
>>>>>> this
>>>
>>>> vote better be cancelled and prepare for a lot of work to get this
>>>>>>>
>>>>>> fixed
>>>>
>>>>> first...
>>>>>>>
>>>>>>> As I already mentioned on the Hyracks release candidate: LICENSE,
>>>>>>>
>>>>>> NOTICE
>>>>
>>>>> and DISCLAIMER requirements apply to all released/distributed
>>>>>>>
>>>>>> artifacts.
>>>>
>>>>> As such, all the build artifacts in the Maven repository also have to
>>>>>>> contain and provide these...
>>>>>>> Please check again the requirements for binary (re)distributions
>>>>>>>
>>>>>> here:
>>>
>>>>
>>>>>>>
>>>>>>> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
>>>
>>>> http://www.apache.org/dev/licensing-howto.html#deps-of-deps
>>>>>>> http://www.apache.org/dev/licensing-howto.html#binary
>>>>>>>
>>>>>>> And in general everything on whole page.
>>>>>>>
>>>>>>> Some of the Maven repo jars already do have the 'verbatim' Apache
>>>>>>>
>>>>>> LICENSE
>>>>
>>>>> and NOTICE files, but none provide the Incubator DISCLAIMER, which in
>>>>>>> addition to the above rules also is required for every distribution
>>>>>>>
>>>>>> from
>>>>
>>>>> the Incubator.
>>>>>>>
>>>>>>> And some others jars don't even bundle a LICENSE and NOTICE file like
>>>>>>> asterix-common-0.8.7-incubating.jar (there are possibly more, I
>>>>>>>
>>>>>> didn't
>>>
>>>> check each and every one).
>>>>>>>
>>>>>>> And besides this, aggregating distributions like all .zip|.tar etc.
>>>>>>>
>>>>>> files
>>>>
>>>>> contain none of these files. Including module -source-release.zip
>>>>>>>
>>>>>> files
>>>
>>>> like asterix-events-0.8.7-incubating-source-release.zip and the
>>>>>>>
>>>>>> -demo.zip
>>>>
>>>>> files.
>>>>>>>
>>>>>>> All of these artifacts when released/distributed have to comply to
>>>>>>>
>>>>>> the
>>>
>>>> above rules.
>>>>>>> Which most definitely isn't a trivial task to comply with and
>>>>>>>
>>>>>> typically
>>>
>>>> takes several iterations to get right... Painful yes, but necessary.
>>>>>>> Once setup and configured properly though, thereafter it usually
>>>>>>>
>>>>>> doesn't
>>>>
>>>>> require a lot of work to keep it up to date.
>>>>>>>
>>>>>>> But getting it right the first time will.
>>>>>>> Just saying so that you'll all be aware this isn't something likely
>>>>>>> fixable in a few minutes or even hours...
>>>>>>>
>>>>>>> Two important things to keep in mind:
>>>>>>> - LICENSE and NOTICE files must be tailored specifically to the
>>>>>>> distribution containing them, providing attribution to what the
>>>>>>> distribution contains, but nothing more.
>>>>>>> For example 3rd party embedded sources like JQuery require license
>>>>>>> attribution, but NOT in artifacts NOT embedding them.
>>>>>>> So the asterix-app should indeed mention this in the LICENSE file in
>>>>>>>
>>>>>> its
>>>>
>>>>> jar AND -binary-assembly.zip, but for example the asterix-algebra jar
>>>>>>> should NOT.
>>>>>>> - Distributions bundling other distributions must aggregate possible
>>>>>>> LICENSE and NOTICE attributions of those other distributions within
>>>>>>>
>>>>>> their
>>>>
>>>>> main LICENSE and NOTICE file.
>>>>>>> So for example, the LICENSE and NOTICE files in the asterix-app
>>>>>>> binary-assembly.zip must aggregate those from the bundled/embedded
>>>>>>> asterix-app *jar*.
>>>>>>> And further more, as the binary-assembly.zip bundles many other,
>>>>>>> including 3rd party, jars, their LICENSE and/or NOTICE attributions
>>>>>>>
>>>>>> needs
>>>>
>>>>> to be aggregated as well (when needed, which depends on the
>>>>>>>
>>>>>> particular
>>>
>>>> LICENSE and/or NOTICE). Including possible other licenses applicable
>>>>>>>
>>>>>> to
>>>
>>>> those bundled jars (or whatever bundled bits).
>>>>>>> And for aggregates of aggregates, like the asterix-installer
>>>>>>> binary-assembly.zip, this has to be done 'transitively'. Yeah, a lot
>>>>>>>
>>>>>> of
>>>
>>>> work indeed.
>>>>>>>
>>>>>>> I also like to refer back to the [DISCUSS] mail I send earlier on the
>>>>>>> Hyracks release candidate, where I already indicated this to become
>>>>>>> critical when releasing binary artifacts.
>>>>>>> And to a few suggestions I gave then like configuring the
>>>>>>> apache-incubator-disclaimer-resource-bundle to ensure the DISCLAIMER
>>>>>>>
>>>>>> file
>>>>
>>>>> will automatically added to all generated jars (but not in assembled
>>>>>>> artifacts).
>>>>>>> And to leverage automatic *appending* specific LICENSE/NOTICE file
>>>>>>> fragments for specific modules which embed 3rd party resources, via
>>>>>>> src/main/appended-resources/META-INF/LICENSE and/or ./NOTICE files.
>>>>>>>
>>>>>>> I'm happy to try help out if this raises questions (and I expect it
>>>>>>> will),
>>>>>>> but that'll be more practical to do case by case.
>>>>>>> Trying to write down such 'guidelines' generically typically just
>>>>>>>
>>>>>> leads
>>>
>>>> to
>>>>>>> more confusion :)
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Ate
>>>>>>>
>>>>>>>
>>>>>>> On 2015-10-05 22:16, Ian Maxon wrote:
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>>>
>>>>>>>> Please verify and vote on the first full Apache AsterixDB release!
>>>>>>>> This candidate addresses some of the differences that were noticed
>>>>>>>> between the tagged commit in git and the source packaging.
>>>>>>>>
>>>>>>>> The tag to be voted on is
>>>>>>>>
>>>>>>>> asterix-0.8.7-incubating
>>>>>>>> commit : d2e1e89cfdf39e2b772dff2600913bb79644a380
>>>>>>>> link:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://git-wip-us.apache.org/repos/asf?p=incubator-asterixdb.git;a=tag;h=refs/tags/asterix-0.8.7-incubating
>>>
>>>>
>>>>>>>> The artifacts, md5s, and signatures are at:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip
>>>
>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.asc
>>>
>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.md5
>>>
>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.sha1
>>>
>>>>
>>>>>>>> MD5: 7330e6d6c2dd691ae3ab6a641e4d5344
>>>>>>>> SHA1: bf0b4a2ceaa26bcf1fcda33fee1ba227e31a88ba
>>>>>>>>
>>>>>>>> Additionally, a staged maven repository is available at:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://repository.apache.org/content/repositories/orgapacheasterix-1014/
>>>
>>>>
>>>>>>>> The KEYS file containing the PGP keys used to sign the release can
>>>>>>>>
>>>>>>> be
>>>
>>>> found at
>>>>>>>>
>>>>>>>> https://dist.apache.org/repos/dist/release/incubator/asterixdb/KEYS
>>>>>>>>
>>>>>>>> RAT was executed as part of Maven via the RAT maven plugin, as well
>>>>>>>>
>>>>>>> as
>>>
>>>> manually, but it
>>>>>>>> excludes the following paths:
>>>>>>>>
>>>>>>>> .*\.adm
>>>>>>>> .*\.aql
>>>>>>>> .*\.cleaned
>>>>>>>> .*\.csv
>>>>>>>> .*\.csv.cr
>>>>>>>> .*\.csv.crlf
>>>>>>>> .*\.csv.lf
>>>>>>>> .*\.ddl
>>>>>>>> .*\.dot
>>>>>>>> .*\.hcli
>>>>>>>> .*\.iml
>>>>>>>> .*\.json
>>>>>>>> .*\.out
>>>>>>>> .*\.plan
>>>>>>>> .*\.ps
>>>>>>>> .*\.scm
>>>>>>>> .*\.tbl
>>>>>>>> .*\.tbl\.big
>>>>>>>> .*\.tsv
>>>>>>>> .*\.txt
>>>>>>>> .*large_text
>>>>>>>> .*part-00000
>>>>>>>> .*part-00001
>>>>>>>>
>>>>>>>> .*\.goutputstream-YQMB2V
>>>>>>>> .*02-fuzzy-select
>>>>>>>> .*LockRequestFile
>>>>>>>> .*hosts
>>>>>>>> .*id_rsa
>>>>>>>> .*known_hosts
>>>>>>>>
>>>>>>>> .*bottle.py
>>>>>>>> .*geostats.js
>>>>>>>> .*jquery.autosize-min.js
>>>>>>>> .*jquery.min.js
>>>>>>>> .*rainbowvis.js
>>>>>>>> .*smoothie.js
>>>>>>>>
>>>>>>>>
>>>>>>>> These files either are either data for tests, procedurally
>>>>>>>>
>>>>>>> generated,
>>>
>>>> or source files which come without a header mentioning their
>>>>>>>>
>>>>>>> license,
>>>
>>>> but have an explicit reference in the LICENSE file.
>>>>>>>>
>>>>>>>> The complete RAT report is available at:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://gist.githubusercontent.com/westmann/b6ed4b25bea44adcd526/raw/be93ff0c1d13c2ce7c88a2b713ace130b5e7ef5f/gistfile1.txt
>>>
>>>>
>>>>>>>> The vote is open for 72 hours, or until the necessary number of
>>>>>>>>
>>>>>>> votes
>>>
>>>> (3 +1) has been reached.
>>>>>>>>
>>>>>>>> Please vote
>>>>>>>> [ ] +1 release this package as Apache AsterixDB 0.8.7-incubating
>>>>>>>> [ ] 0 No strong feeling either way
>>>>>>>> [ ] -1 do not release this package because ...
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> -Ian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>

Re: [DISCUSS] Release Apache AsterixDB 0.8.7-incubating (RC3)

[Till Westmann <ti...@apache.org>]

I think that the answer is “it depends”.
It should be clear that the download is not an ASF artifact.
If we provide that artifact from an apache.org address that’s more
difficult to communicate than if we provide it e.g. from a uci.edu
address.

Who are the end-users that download today?
Are they mostly students/researchers or is the audience wider than that?

Thanks,
Till

On 8 Oct 2015, at 13:48, Chris Hillery wrote:

> Could we continue to provide those binary artifacts as "unofficial"
> releases via our own website?
>
> Ceej
> aka Chris Hillery
> On Oct 8, 2015 1:40 PM, "Ian Maxon" <im...@uci.edu> wrote:
>
>> Hm, alright, if that's something that seems valuable, then I'm OK 
>> with it.
>> I suppose my eyes were set on getting the asterix-installer and
>> asterix-yarn packagings out, since that's usually what end-users are
>> downloading first. It is true that this has taken a lot longer than I 
>> think
>> anyone would've liked.
>>
>> -Ian
>>
>> On Thu, Oct 8, 2015 at 1:25 PM, Chris Hillery <ch...@hillery.land>
>> wrote:
>>
>>> That sounds like a reasonable idea to me. If Ate is right that this
>> usually
>>> takes several releases to get correct, it could be a really long 
>>> time
>>> before we have binaries fully ready to go. This release has already 
>>> taken
>>> months longer than expected; let's have a source-only release for 
>>> now so
>> we
>>> can continue moving forward.
>>>
>>> Ceej
>>> aka Chris Hillery
>>> On Oct 8, 2015 1:15 PM, "Till Westmann" <ti...@apache.org> wrote:
>>>
>>>> Would it also be an option to
>>>> a) release the current release in source-only form,
>>>> b) not advertise/distribute the binaries for now, and
>>>> c) fix this for the next release?
>>>>
>>>> Right now we have zero AsterixDB releases at the ASF and that way
>>>> we could have one that people have to build on their own (which is
>>>> the usual way at the ASF and no rocket science for any developer).
>>>> Also, I think that individual developer can still build a binary 
>>>> and
>>>> give it to someone for testing, it’s just not an ASF artifact at
>>>> that point.
>>>>
>>>> Thoughts/Concerns?
>>>>
>>>> Cheers,
>>>> Till
>>>>
>>>>
>>>> On 7 Oct 2015, at 15:49, Ian Maxon wrote:
>>>>
>>>> I see, thank you for the very detailed analysis Ate. I think we 
>>>> will
>> have
>>>>> to fix all of the binary assemblies to conform.  What's in Maven 
>>>>> is
>>>>> important, as well as the bundled zips and such. Our usual method 
>>>>> of
>>>>> distribution to end-users is via those bundled zips, rather than
>> source.
>>>>> In
>>>>> fact we actually had to add the source assembly specifically for
>> voting,
>>>>> typically developers or folks who need special patches simply 
>>>>> check
>> out
>>>>> from git.
>>>>> More info/updates to come as I dig into how to coax maven into 
>>>>> doing
>>> this
>>>>> nicely...
>>>>>
>>>>> Thanks again,
>>>>> -Ian
>>>>>
>>>>> On Wed, Oct 7, 2015 at 3:24 PM, Ate Douma <at...@douma.nu> wrote:
>>>>>
>>>>> Hi team,
>>>>>>
>>>>>> I either can +1 or -1 this release candidate, depending on if the
>>> staged
>>>>>> maven repository provided artifacts are also intended to be
>>>>>> distributed...
>>>>>>
>>>>>> For just the source release (like for the Hyracks release), I 
>>>>>> think
>> it
>>> is
>>>>>> good to go, so +1 for that.
>>>>>>
>>>>>> But for the binary artifacts in the Maven repo, it is definitely 
>>>>>> a
>> -1.
>>>>>>
>>>>>> So either you'll drop/skip releasing to the Maven repo for this 
>>>>>> time,
>>> and
>>>>>> then you might be good (pending possible feedback from others), 
>>>>>> or
>> this
>>>>>> vote better be cancelled and prepare for a lot of work to get 
>>>>>> this
>>> fixed
>>>>>> first...
>>>>>>
>>>>>> As I already mentioned on the Hyracks release candidate: LICENSE,
>>> NOTICE
>>>>>> and DISCLAIMER requirements apply to all released/distributed
>>> artifacts.
>>>>>> As such, all the build artifacts in the Maven repository also 
>>>>>> have to
>>>>>> contain and provide these...
>>>>>> Please check again the requirements for binary (re)distributions
>> here:
>>>>>>
>>>>>>
>> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
>>>>>> http://www.apache.org/dev/licensing-howto.html#deps-of-deps
>>>>>> http://www.apache.org/dev/licensing-howto.html#binary
>>>>>>
>>>>>> And in general everything on whole page.
>>>>>>
>>>>>> Some of the Maven repo jars already do have the 'verbatim' Apache
>>> LICENSE
>>>>>> and NOTICE files, but none provide the Incubator DISCLAIMER, 
>>>>>> which in
>>>>>> addition to the above rules also is required for every 
>>>>>> distribution
>>> from
>>>>>> the Incubator.
>>>>>>
>>>>>> And some others jars don't even bundle a LICENSE and NOTICE file 
>>>>>> like
>>>>>> asterix-common-0.8.7-incubating.jar (there are possibly more, I
>> didn't
>>>>>> check each and every one).
>>>>>>
>>>>>> And besides this, aggregating distributions like all .zip|.tar 
>>>>>> etc.
>>> files
>>>>>> contain none of these files. Including module -source-release.zip
>> files
>>>>>> like asterix-events-0.8.7-incubating-source-release.zip and the
>>> -demo.zip
>>>>>> files.
>>>>>>
>>>>>> All of these artifacts when released/distributed have to comply 
>>>>>> to
>> the
>>>>>> above rules.
>>>>>> Which most definitely isn't a trivial task to comply with and
>> typically
>>>>>> takes several iterations to get right... Painful yes, but 
>>>>>> necessary.
>>>>>> Once setup and configured properly though, thereafter it usually
>>> doesn't
>>>>>> require a lot of work to keep it up to date.
>>>>>>
>>>>>> But getting it right the first time will.
>>>>>> Just saying so that you'll all be aware this isn't something 
>>>>>> likely
>>>>>> fixable in a few minutes or even hours...
>>>>>>
>>>>>> Two important things to keep in mind:
>>>>>> - LICENSE and NOTICE files must be tailored specifically to the
>>>>>> distribution containing them, providing attribution to what the
>>>>>> distribution contains, but nothing more.
>>>>>> For example 3rd party embedded sources like JQuery require 
>>>>>> license
>>>>>> attribution, but NOT in artifacts NOT embedding them.
>>>>>> So the asterix-app should indeed mention this in the LICENSE file 
>>>>>> in
>>> its
>>>>>> jar AND -binary-assembly.zip, but for example the asterix-algebra 
>>>>>> jar
>>>>>> should NOT.
>>>>>> - Distributions bundling other distributions must aggregate 
>>>>>> possible
>>>>>> LICENSE and NOTICE attributions of those other distributions 
>>>>>> within
>>> their
>>>>>> main LICENSE and NOTICE file.
>>>>>> So for example, the LICENSE and NOTICE files in the asterix-app
>>>>>> binary-assembly.zip must aggregate those from the 
>>>>>> bundled/embedded
>>>>>> asterix-app *jar*.
>>>>>> And further more, as the binary-assembly.zip bundles many other,
>>>>>> including 3rd party, jars, their LICENSE and/or NOTICE 
>>>>>> attributions
>>> needs
>>>>>> to be aggregated as well (when needed, which depends on the
>> particular
>>>>>> LICENSE and/or NOTICE). Including possible other licenses 
>>>>>> applicable
>> to
>>>>>> those bundled jars (or whatever bundled bits).
>>>>>> And for aggregates of aggregates, like the asterix-installer
>>>>>> binary-assembly.zip, this has to be done 'transitively'. Yeah, a 
>>>>>> lot
>> of
>>>>>> work indeed.
>>>>>>
>>>>>> I also like to refer back to the [DISCUSS] mail I send earlier on 
>>>>>> the
>>>>>> Hyracks release candidate, where I already indicated this to 
>>>>>> become
>>>>>> critical when releasing binary artifacts.
>>>>>> And to a few suggestions I gave then like configuring the
>>>>>> apache-incubator-disclaimer-resource-bundle to ensure the 
>>>>>> DISCLAIMER
>>> file
>>>>>> will automatically added to all generated jars (but not in 
>>>>>> assembled
>>>>>> artifacts).
>>>>>> And to leverage automatic *appending* specific LICENSE/NOTICE 
>>>>>> file
>>>>>> fragments for specific modules which embed 3rd party resources, 
>>>>>> via
>>>>>> src/main/appended-resources/META-INF/LICENSE and/or ./NOTICE 
>>>>>> files.
>>>>>>
>>>>>> I'm happy to try help out if this raises questions (and I expect 
>>>>>> it
>>>>>> will),
>>>>>> but that'll be more practical to do case by case.
>>>>>> Trying to write down such 'guidelines' generically typically just
>> leads
>>>>>> to
>>>>>> more confusion :)
>>>>>>
>>>>>> Kind regards,
>>>>>> Ate
>>>>>>
>>>>>>
>>>>>> On 2015-10-05 22:16, Ian Maxon wrote:
>>>>>>
>>>>>> Hi everyone,
>>>>>>>
>>>>>>> Please verify and vote on the first full Apache AsterixDB 
>>>>>>> release!
>>>>>>> This candidate addresses some of the differences that were 
>>>>>>> noticed
>>>>>>> between the tagged commit in git and the source packaging.
>>>>>>>
>>>>>>> The tag to be voted on is
>>>>>>>
>>>>>>> asterix-0.8.7-incubating
>>>>>>> commit : d2e1e89cfdf39e2b772dff2600913bb79644a380
>>>>>>> link:
>>>>>>>
>>>>>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-asterixdb.git;a=tag;h=refs/tags/asterix-0.8.7-incubating
>>>>>>>
>>>>>>> The artifacts, md5s, and signatures are at:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.asc
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.md5
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.sha1
>>>>>>>
>>>>>>> MD5: 7330e6d6c2dd691ae3ab6a641e4d5344
>>>>>>> SHA1: bf0b4a2ceaa26bcf1fcda33fee1ba227e31a88ba
>>>>>>>
>>>>>>> Additionally, a staged maven repository is available at:
>>>>>>>
>>>>>>>
>>>
>> https://repository.apache.org/content/repositories/orgapacheasterix-1014/
>>>>>>>
>>>>>>> The KEYS file containing the PGP keys used to sign the release 
>>>>>>> can
>> be
>>>>>>> found at
>>>>>>>
>>>>>>> https://dist.apache.org/repos/dist/release/incubator/asterixdb/KEYS
>>>>>>>
>>>>>>> RAT was executed as part of Maven via the RAT maven plugin, as 
>>>>>>> well
>> as
>>>>>>> manually, but it
>>>>>>> excludes the following paths:
>>>>>>>
>>>>>>> .*\.adm
>>>>>>> .*\.aql
>>>>>>> .*\.cleaned
>>>>>>> .*\.csv
>>>>>>> .*\.csv.cr
>>>>>>> .*\.csv.crlf
>>>>>>> .*\.csv.lf
>>>>>>> .*\.ddl
>>>>>>> .*\.dot
>>>>>>> .*\.hcli
>>>>>>> .*\.iml
>>>>>>> .*\.json
>>>>>>> .*\.out
>>>>>>> .*\.plan
>>>>>>> .*\.ps
>>>>>>> .*\.scm
>>>>>>> .*\.tbl
>>>>>>> .*\.tbl\.big
>>>>>>> .*\.tsv
>>>>>>> .*\.txt
>>>>>>> .*large_text
>>>>>>> .*part-00000
>>>>>>> .*part-00001
>>>>>>>
>>>>>>> .*\.goutputstream-YQMB2V
>>>>>>> .*02-fuzzy-select
>>>>>>> .*LockRequestFile
>>>>>>> .*hosts
>>>>>>> .*id_rsa
>>>>>>> .*known_hosts
>>>>>>>
>>>>>>> .*bottle.py
>>>>>>> .*geostats.js
>>>>>>> .*jquery.autosize-min.js
>>>>>>> .*jquery.min.js
>>>>>>> .*rainbowvis.js
>>>>>>> .*smoothie.js
>>>>>>>
>>>>>>>
>>>>>>> These files either are either data for tests, procedurally
>> generated,
>>>>>>> or source files which come without a header mentioning their
>> license,
>>>>>>> but have an explicit reference in the LICENSE file.
>>>>>>>
>>>>>>> The complete RAT report is available at:
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>> https://gist.githubusercontent.com/westmann/b6ed4b25bea44adcd526/raw/be93ff0c1d13c2ce7c88a2b713ace130b5e7ef5f/gistfile1.txt
>>>>>>>
>>>>>>> The vote is open for 72 hours, or until the necessary number of
>> votes
>>>>>>> (3 +1) has been reached.
>>>>>>>
>>>>>>> Please vote
>>>>>>> [ ] +1 release this package as Apache AsterixDB 0.8.7-incubating
>>>>>>> [ ] 0 No strong feeling either way
>>>>>>> [ ] -1 do not release this package because ...
>>>>>>>
>>>>>>> Thanks!
>>>>>>> -Ian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>>

Re: [DISCUSS] Release Apache AsterixDB 0.8.7-incubating (RC3)

[Mike Carey <dt...@gmail.com>]

I think that's the answer for this release, and then we should hold off on
future releases until we get this form of the bits release-able to.  (IMO)
On Oct 9, 2015 2:59 AM, "Ate Douma" <at...@douma.nu> wrote:

> On 2015-10-08 22:48, Chris Hillery wrote:
>
>> Could we continue to provide those binary artifacts as "unofficial"
>> releases via our own website?
>>
>
> No.
> Please check:
> http://www.apache.org/dev/release-distribution.html#unreleased
>
> For the record "those binary artifacts" simply don't exists from a project
> POV if not formally released, and there is no such thing as an "unofficial"
> release.
>
> Of course, anyone can build such artifacts based on the source release,
> and host them somewhere (but definitely not ASF).
> But these artifacts are not and cannot be labelled or claimed to be
> provided or even just endorsed by the project in relation to this release.
> They simply will be 'just' some build artifacts, hosted somewhere,
> provided by someone, with no guarantee whatsoever they actually represent
> the AsterixDB (source) release.
> And the project thus also cannot 'announce' these with any higher claim
> (so in practice there is no claim) to the community, maybe just to the core
> developers (dev@).
> Targeting this to users outside this limited domain is definitely not
> allowed.
>
> This might all seem to be overly formalistic, but if you think about it,
> it really touches upon one of the most core principles of the ASF:
> providing trust in the quality and due diligence exercised on releases
> provided to the community. The community needs to be able to rely on
> artifacts and releases provided by the ASF to be properly validated, vetted
> and endorsed by the project.
> And *anything* which might jeopardize this trust will raise questions and
> likely be voted down, or required to be fixed after the fact.
>
> That all said, it should be fine if someone builds and hosts such
> artifacts somewhere else, as long as they are NOT announced, linked to or
> otherwise endorsed in any other way by the project.
> How useful that then ends up to be, I don't know.
>
> As I understand those users targeted with these artifacts just as well or
> easily can build the release themselves locally, I wonder if (for this
> release) it might be more pragmatic to just tell them to do so.
>
> Ate
>
>
>> Ceej
>> aka Chris Hillery
>> On Oct 8, 2015 1:40 PM, "Ian Maxon" <im...@uci.edu> wrote:
>>
>> Hm, alright, if that's something that seems valuable, then I'm OK with it.
>>> I suppose my eyes were set on getting the asterix-installer and
>>> asterix-yarn packagings out, since that's usually what end-users are
>>> downloading first. It is true that this has taken a lot longer than I
>>> think
>>> anyone would've liked.
>>>
>>> -Ian
>>>
>>> On Thu, Oct 8, 2015 at 1:25 PM, Chris Hillery <ch...@hillery.land>
>>> wrote:
>>>
>>> That sounds like a reasonable idea to me. If Ate is right that this
>>>>
>>> usually
>>>
>>>> takes several releases to get correct, it could be a really long time
>>>> before we have binaries fully ready to go. This release has already
>>>> taken
>>>> months longer than expected; let's have a source-only release for now so
>>>>
>>> we
>>>
>>>> can continue moving forward.
>>>>
>>>> Ceej
>>>> aka Chris Hillery
>>>> On Oct 8, 2015 1:15 PM, "Till Westmann" <ti...@apache.org> wrote:
>>>>
>>>> Would it also be an option to
>>>>> a) release the current release in source-only form,
>>>>> b) not advertise/distribute the binaries for now, and
>>>>> c) fix this for the next release?
>>>>>
>>>>> Right now we have zero AsterixDB releases at the ASF and that way
>>>>> we could have one that people have to build on their own (which is
>>>>> the usual way at the ASF and no rocket science for any developer).
>>>>> Also, I think that individual developer can still build a binary and
>>>>> give it to someone for testing, it’s just not an ASF artifact at
>>>>> that point.
>>>>>
>>>>> Thoughts/Concerns?
>>>>>
>>>>> Cheers,
>>>>> Till
>>>>>
>>>>>
>>>>> On 7 Oct 2015, at 15:49, Ian Maxon wrote:
>>>>>
>>>>> I see, thank you for the very detailed analysis Ate. I think we will
>>>>>
>>>> have
>>>
>>>> to fix all of the binary assemblies to conform.  What's in Maven is
>>>>>> important, as well as the bundled zips and such. Our usual method of
>>>>>> distribution to end-users is via those bundled zips, rather than
>>>>>>
>>>>> source.
>>>
>>>> In
>>>>>> fact we actually had to add the source assembly specifically for
>>>>>>
>>>>> voting,
>>>
>>>> typically developers or folks who need special patches simply check
>>>>>>
>>>>> out
>>>
>>>> from git.
>>>>>> More info/updates to come as I dig into how to coax maven into doing
>>>>>>
>>>>> this
>>>>
>>>>> nicely...
>>>>>>
>>>>>> Thanks again,
>>>>>> -Ian
>>>>>>
>>>>>> On Wed, Oct 7, 2015 at 3:24 PM, Ate Douma <at...@douma.nu> wrote:
>>>>>>
>>>>>> Hi team,
>>>>>>
>>>>>>>
>>>>>>> I either can +1 or -1 this release candidate, depending on if the
>>>>>>>
>>>>>> staged
>>>>
>>>>> maven repository provided artifacts are also intended to be
>>>>>>> distributed...
>>>>>>>
>>>>>>> For just the source release (like for the Hyracks release), I think
>>>>>>>
>>>>>> it
>>>
>>>> is
>>>>
>>>>> good to go, so +1 for that.
>>>>>>>
>>>>>>> But for the binary artifacts in the Maven repo, it is definitely a
>>>>>>>
>>>>>> -1.
>>>
>>>>
>>>>>>> So either you'll drop/skip releasing to the Maven repo for this time,
>>>>>>>
>>>>>> and
>>>>
>>>>> then you might be good (pending possible feedback from others), or
>>>>>>>
>>>>>> this
>>>
>>>> vote better be cancelled and prepare for a lot of work to get this
>>>>>>>
>>>>>> fixed
>>>>
>>>>> first...
>>>>>>>
>>>>>>> As I already mentioned on the Hyracks release candidate: LICENSE,
>>>>>>>
>>>>>> NOTICE
>>>>
>>>>> and DISCLAIMER requirements apply to all released/distributed
>>>>>>>
>>>>>> artifacts.
>>>>
>>>>> As such, all the build artifacts in the Maven repository also have to
>>>>>>> contain and provide these...
>>>>>>> Please check again the requirements for binary (re)distributions
>>>>>>>
>>>>>> here:
>>>
>>>>
>>>>>>>
>>>>>>> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
>>>
>>>> http://www.apache.org/dev/licensing-howto.html#deps-of-deps
>>>>>>> http://www.apache.org/dev/licensing-howto.html#binary
>>>>>>>
>>>>>>> And in general everything on whole page.
>>>>>>>
>>>>>>> Some of the Maven repo jars already do have the 'verbatim' Apache
>>>>>>>
>>>>>> LICENSE
>>>>
>>>>> and NOTICE files, but none provide the Incubator DISCLAIMER, which in
>>>>>>> addition to the above rules also is required for every distribution
>>>>>>>
>>>>>> from
>>>>
>>>>> the Incubator.
>>>>>>>
>>>>>>> And some others jars don't even bundle a LICENSE and NOTICE file like
>>>>>>> asterix-common-0.8.7-incubating.jar (there are possibly more, I
>>>>>>>
>>>>>> didn't
>>>
>>>> check each and every one).
>>>>>>>
>>>>>>> And besides this, aggregating distributions like all .zip|.tar etc.
>>>>>>>
>>>>>> files
>>>>
>>>>> contain none of these files. Including module -source-release.zip
>>>>>>>
>>>>>> files
>>>
>>>> like asterix-events-0.8.7-incubating-source-release.zip and the
>>>>>>>
>>>>>> -demo.zip
>>>>
>>>>> files.
>>>>>>>
>>>>>>> All of these artifacts when released/distributed have to comply to
>>>>>>>
>>>>>> the
>>>
>>>> above rules.
>>>>>>> Which most definitely isn't a trivial task to comply with and
>>>>>>>
>>>>>> typically
>>>
>>>> takes several iterations to get right... Painful yes, but necessary.
>>>>>>> Once setup and configured properly though, thereafter it usually
>>>>>>>
>>>>>> doesn't
>>>>
>>>>> require a lot of work to keep it up to date.
>>>>>>>
>>>>>>> But getting it right the first time will.
>>>>>>> Just saying so that you'll all be aware this isn't something likely
>>>>>>> fixable in a few minutes or even hours...
>>>>>>>
>>>>>>> Two important things to keep in mind:
>>>>>>> - LICENSE and NOTICE files must be tailored specifically to the
>>>>>>> distribution containing them, providing attribution to what the
>>>>>>> distribution contains, but nothing more.
>>>>>>> For example 3rd party embedded sources like JQuery require license
>>>>>>> attribution, but NOT in artifacts NOT embedding them.
>>>>>>> So the asterix-app should indeed mention this in the LICENSE file in
>>>>>>>
>>>>>> its
>>>>
>>>>> jar AND -binary-assembly.zip, but for example the asterix-algebra jar
>>>>>>> should NOT.
>>>>>>> - Distributions bundling other distributions must aggregate possible
>>>>>>> LICENSE and NOTICE attributions of those other distributions within
>>>>>>>
>>>>>> their
>>>>
>>>>> main LICENSE and NOTICE file.
>>>>>>> So for example, the LICENSE and NOTICE files in the asterix-app
>>>>>>> binary-assembly.zip must aggregate those from the bundled/embedded
>>>>>>> asterix-app *jar*.
>>>>>>> And further more, as the binary-assembly.zip bundles many other,
>>>>>>> including 3rd party, jars, their LICENSE and/or NOTICE attributions
>>>>>>>
>>>>>> needs
>>>>
>>>>> to be aggregated as well (when needed, which depends on the
>>>>>>>
>>>>>> particular
>>>
>>>> LICENSE and/or NOTICE). Including possible other licenses applicable
>>>>>>>
>>>>>> to
>>>
>>>> those bundled jars (or whatever bundled bits).
>>>>>>> And for aggregates of aggregates, like the asterix-installer
>>>>>>> binary-assembly.zip, this has to be done 'transitively'. Yeah, a lot
>>>>>>>
>>>>>> of
>>>
>>>> work indeed.
>>>>>>>
>>>>>>> I also like to refer back to the [DISCUSS] mail I send earlier on the
>>>>>>> Hyracks release candidate, where I already indicated this to become
>>>>>>> critical when releasing binary artifacts.
>>>>>>> And to a few suggestions I gave then like configuring the
>>>>>>> apache-incubator-disclaimer-resource-bundle to ensure the DISCLAIMER
>>>>>>>
>>>>>> file
>>>>
>>>>> will automatically added to all generated jars (but not in assembled
>>>>>>> artifacts).
>>>>>>> And to leverage automatic *appending* specific LICENSE/NOTICE file
>>>>>>> fragments for specific modules which embed 3rd party resources, via
>>>>>>> src/main/appended-resources/META-INF/LICENSE and/or ./NOTICE files.
>>>>>>>
>>>>>>> I'm happy to try help out if this raises questions (and I expect it
>>>>>>> will),
>>>>>>> but that'll be more practical to do case by case.
>>>>>>> Trying to write down such 'guidelines' generically typically just
>>>>>>>
>>>>>> leads
>>>
>>>> to
>>>>>>> more confusion :)
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Ate
>>>>>>>
>>>>>>>
>>>>>>> On 2015-10-05 22:16, Ian Maxon wrote:
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>>>
>>>>>>>> Please verify and vote on the first full Apache AsterixDB release!
>>>>>>>> This candidate addresses some of the differences that were noticed
>>>>>>>> between the tagged commit in git and the source packaging.
>>>>>>>>
>>>>>>>> The tag to be voted on is
>>>>>>>>
>>>>>>>> asterix-0.8.7-incubating
>>>>>>>> commit : d2e1e89cfdf39e2b772dff2600913bb79644a380
>>>>>>>> link:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://git-wip-us.apache.org/repos/asf?p=incubator-asterixdb.git;a=tag;h=refs/tags/asterix-0.8.7-incubating
>>>
>>>>
>>>>>>>> The artifacts, md5s, and signatures are at:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip
>>>
>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.asc
>>>
>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.md5
>>>
>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.sha1
>>>
>>>>
>>>>>>>> MD5: 7330e6d6c2dd691ae3ab6a641e4d5344
>>>>>>>> SHA1: bf0b4a2ceaa26bcf1fcda33fee1ba227e31a88ba
>>>>>>>>
>>>>>>>> Additionally, a staged maven repository is available at:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://repository.apache.org/content/repositories/orgapacheasterix-1014/
>>>
>>>>
>>>>>>>> The KEYS file containing the PGP keys used to sign the release can
>>>>>>>>
>>>>>>> be
>>>
>>>> found at
>>>>>>>>
>>>>>>>> https://dist.apache.org/repos/dist/release/incubator/asterixdb/KEYS
>>>>>>>>
>>>>>>>> RAT was executed as part of Maven via the RAT maven plugin, as well
>>>>>>>>
>>>>>>> as
>>>
>>>> manually, but it
>>>>>>>> excludes the following paths:
>>>>>>>>
>>>>>>>> .*\.adm
>>>>>>>> .*\.aql
>>>>>>>> .*\.cleaned
>>>>>>>> .*\.csv
>>>>>>>> .*\.csv.cr
>>>>>>>> .*\.csv.crlf
>>>>>>>> .*\.csv.lf
>>>>>>>> .*\.ddl
>>>>>>>> .*\.dot
>>>>>>>> .*\.hcli
>>>>>>>> .*\.iml
>>>>>>>> .*\.json
>>>>>>>> .*\.out
>>>>>>>> .*\.plan
>>>>>>>> .*\.ps
>>>>>>>> .*\.scm
>>>>>>>> .*\.tbl
>>>>>>>> .*\.tbl\.big
>>>>>>>> .*\.tsv
>>>>>>>> .*\.txt
>>>>>>>> .*large_text
>>>>>>>> .*part-00000
>>>>>>>> .*part-00001
>>>>>>>>
>>>>>>>> .*\.goutputstream-YQMB2V
>>>>>>>> .*02-fuzzy-select
>>>>>>>> .*LockRequestFile
>>>>>>>> .*hosts
>>>>>>>> .*id_rsa
>>>>>>>> .*known_hosts
>>>>>>>>
>>>>>>>> .*bottle.py
>>>>>>>> .*geostats.js
>>>>>>>> .*jquery.autosize-min.js
>>>>>>>> .*jquery.min.js
>>>>>>>> .*rainbowvis.js
>>>>>>>> .*smoothie.js
>>>>>>>>
>>>>>>>>
>>>>>>>> These files either are either data for tests, procedurally
>>>>>>>>
>>>>>>> generated,
>>>
>>>> or source files which come without a header mentioning their
>>>>>>>>
>>>>>>> license,
>>>
>>>> but have an explicit reference in the LICENSE file.
>>>>>>>>
>>>>>>>> The complete RAT report is available at:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>> https://gist.githubusercontent.com/westmann/b6ed4b25bea44adcd526/raw/be93ff0c1d13c2ce7c88a2b713ace130b5e7ef5f/gistfile1.txt
>>>
>>>>
>>>>>>>> The vote is open for 72 hours, or until the necessary number of
>>>>>>>>
>>>>>>> votes
>>>
>>>> (3 +1) has been reached.
>>>>>>>>
>>>>>>>> Please vote
>>>>>>>> [ ] +1 release this package as Apache AsterixDB 0.8.7-incubating
>>>>>>>> [ ] 0 No strong feeling either way
>>>>>>>> [ ] -1 do not release this package because ...
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> -Ian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>
>>
>
>

Re: [DISCUSS] Release Apache AsterixDB 0.8.7-incubating (RC3)

[Ate Douma <at...@douma.nu>]

On 2015-10-08 22:48, Chris Hillery wrote:
> Could we continue to provide those binary artifacts as "unofficial"
> releases via our own website?

No.
Please check: http://www.apache.org/dev/release-distribution.html#unreleased

For the record "those binary artifacts" simply don't exists from a project POV 
if not formally released, and there is no such thing as an "unofficial" release.

Of course, anyone can build such artifacts based on the source release, and host 
them somewhere (but definitely not ASF).
But these artifacts are not and cannot be labelled or claimed to be provided or 
even just endorsed by the project in relation to this release.
They simply will be 'just' some build artifacts, hosted somewhere, provided by 
someone, with no guarantee whatsoever they actually represent the AsterixDB 
(source) release.
And the project thus also cannot 'announce' these with any higher claim (so in 
practice there is no claim) to the community, maybe just to the core developers 
(dev@).
Targeting this to users outside this limited domain is definitely not allowed.

This might all seem to be overly formalistic, but if you think about it, it 
really touches upon one of the most core principles of the ASF: providing trust 
in the quality and due diligence exercised on releases provided to the 
community. The community needs to be able to rely on artifacts and releases 
provided by the ASF to be properly validated, vetted and endorsed by the project.
And *anything* which might jeopardize this trust will raise questions and likely 
be voted down, or required to be fixed after the fact.

That all said, it should be fine if someone builds and hosts such artifacts 
somewhere else, as long as they are NOT announced, linked to or otherwise 
endorsed in any other way by the project.
How useful that then ends up to be, I don't know.

As I understand those users targeted with these artifacts just as well or easily 
can build the release themselves locally, I wonder if (for this release) it 
might be more pragmatic to just tell them to do so.

Ate

>
> Ceej
> aka Chris Hillery
> On Oct 8, 2015 1:40 PM, "Ian Maxon" <im...@uci.edu> wrote:
>
>> Hm, alright, if that's something that seems valuable, then I'm OK with it.
>> I suppose my eyes were set on getting the asterix-installer and
>> asterix-yarn packagings out, since that's usually what end-users are
>> downloading first. It is true that this has taken a lot longer than I think
>> anyone would've liked.
>>
>> -Ian
>>
>> On Thu, Oct 8, 2015 at 1:25 PM, Chris Hillery <ch...@hillery.land>
>> wrote:
>>
>>> That sounds like a reasonable idea to me. If Ate is right that this
>> usually
>>> takes several releases to get correct, it could be a really long time
>>> before we have binaries fully ready to go. This release has already taken
>>> months longer than expected; let's have a source-only release for now so
>> we
>>> can continue moving forward.
>>>
>>> Ceej
>>> aka Chris Hillery
>>> On Oct 8, 2015 1:15 PM, "Till Westmann" <ti...@apache.org> wrote:
>>>
>>>> Would it also be an option to
>>>> a) release the current release in source-only form,
>>>> b) not advertise/distribute the binaries for now, and
>>>> c) fix this for the next release?
>>>>
>>>> Right now we have zero AsterixDB releases at the ASF and that way
>>>> we could have one that people have to build on their own (which is
>>>> the usual way at the ASF and no rocket science for any developer).
>>>> Also, I think that individual developer can still build a binary and
>>>> give it to someone for testing, it’s just not an ASF artifact at
>>>> that point.
>>>>
>>>> Thoughts/Concerns?
>>>>
>>>> Cheers,
>>>> Till
>>>>
>>>>
>>>> On 7 Oct 2015, at 15:49, Ian Maxon wrote:
>>>>
>>>> I see, thank you for the very detailed analysis Ate. I think we will
>> have
>>>>> to fix all of the binary assemblies to conform.  What's in Maven is
>>>>> important, as well as the bundled zips and such. Our usual method of
>>>>> distribution to end-users is via those bundled zips, rather than
>> source.
>>>>> In
>>>>> fact we actually had to add the source assembly specifically for
>> voting,
>>>>> typically developers or folks who need special patches simply check
>> out
>>>>> from git.
>>>>> More info/updates to come as I dig into how to coax maven into doing
>>> this
>>>>> nicely...
>>>>>
>>>>> Thanks again,
>>>>> -Ian
>>>>>
>>>>> On Wed, Oct 7, 2015 at 3:24 PM, Ate Douma <at...@douma.nu> wrote:
>>>>>
>>>>> Hi team,
>>>>>>
>>>>>> I either can +1 or -1 this release candidate, depending on if the
>>> staged
>>>>>> maven repository provided artifacts are also intended to be
>>>>>> distributed...
>>>>>>
>>>>>> For just the source release (like for the Hyracks release), I think
>> it
>>> is
>>>>>> good to go, so +1 for that.
>>>>>>
>>>>>> But for the binary artifacts in the Maven repo, it is definitely a
>> -1.
>>>>>>
>>>>>> So either you'll drop/skip releasing to the Maven repo for this time,
>>> and
>>>>>> then you might be good (pending possible feedback from others), or
>> this
>>>>>> vote better be cancelled and prepare for a lot of work to get this
>>> fixed
>>>>>> first...
>>>>>>
>>>>>> As I already mentioned on the Hyracks release candidate: LICENSE,
>>> NOTICE
>>>>>> and DISCLAIMER requirements apply to all released/distributed
>>> artifacts.
>>>>>> As such, all the build artifacts in the Maven repository also have to
>>>>>> contain and provide these...
>>>>>> Please check again the requirements for binary (re)distributions
>> here:
>>>>>>
>>>>>>
>> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
>>>>>> http://www.apache.org/dev/licensing-howto.html#deps-of-deps
>>>>>> http://www.apache.org/dev/licensing-howto.html#binary
>>>>>>
>>>>>> And in general everything on whole page.
>>>>>>
>>>>>> Some of the Maven repo jars already do have the 'verbatim' Apache
>>> LICENSE
>>>>>> and NOTICE files, but none provide the Incubator DISCLAIMER, which in
>>>>>> addition to the above rules also is required for every distribution
>>> from
>>>>>> the Incubator.
>>>>>>
>>>>>> And some others jars don't even bundle a LICENSE and NOTICE file like
>>>>>> asterix-common-0.8.7-incubating.jar (there are possibly more, I
>> didn't
>>>>>> check each and every one).
>>>>>>
>>>>>> And besides this, aggregating distributions like all .zip|.tar etc.
>>> files
>>>>>> contain none of these files. Including module -source-release.zip
>> files
>>>>>> like asterix-events-0.8.7-incubating-source-release.zip and the
>>> -demo.zip
>>>>>> files.
>>>>>>
>>>>>> All of these artifacts when released/distributed have to comply to
>> the
>>>>>> above rules.
>>>>>> Which most definitely isn't a trivial task to comply with and
>> typically
>>>>>> takes several iterations to get right... Painful yes, but necessary.
>>>>>> Once setup and configured properly though, thereafter it usually
>>> doesn't
>>>>>> require a lot of work to keep it up to date.
>>>>>>
>>>>>> But getting it right the first time will.
>>>>>> Just saying so that you'll all be aware this isn't something likely
>>>>>> fixable in a few minutes or even hours...
>>>>>>
>>>>>> Two important things to keep in mind:
>>>>>> - LICENSE and NOTICE files must be tailored specifically to the
>>>>>> distribution containing them, providing attribution to what the
>>>>>> distribution contains, but nothing more.
>>>>>> For example 3rd party embedded sources like JQuery require license
>>>>>> attribution, but NOT in artifacts NOT embedding them.
>>>>>> So the asterix-app should indeed mention this in the LICENSE file in
>>> its
>>>>>> jar AND -binary-assembly.zip, but for example the asterix-algebra jar
>>>>>> should NOT.
>>>>>> - Distributions bundling other distributions must aggregate possible
>>>>>> LICENSE and NOTICE attributions of those other distributions within
>>> their
>>>>>> main LICENSE and NOTICE file.
>>>>>> So for example, the LICENSE and NOTICE files in the asterix-app
>>>>>> binary-assembly.zip must aggregate those from the bundled/embedded
>>>>>> asterix-app *jar*.
>>>>>> And further more, as the binary-assembly.zip bundles many other,
>>>>>> including 3rd party, jars, their LICENSE and/or NOTICE attributions
>>> needs
>>>>>> to be aggregated as well (when needed, which depends on the
>> particular
>>>>>> LICENSE and/or NOTICE). Including possible other licenses applicable
>> to
>>>>>> those bundled jars (or whatever bundled bits).
>>>>>> And for aggregates of aggregates, like the asterix-installer
>>>>>> binary-assembly.zip, this has to be done 'transitively'. Yeah, a lot
>> of
>>>>>> work indeed.
>>>>>>
>>>>>> I also like to refer back to the [DISCUSS] mail I send earlier on the
>>>>>> Hyracks release candidate, where I already indicated this to become
>>>>>> critical when releasing binary artifacts.
>>>>>> And to a few suggestions I gave then like configuring the
>>>>>> apache-incubator-disclaimer-resource-bundle to ensure the DISCLAIMER
>>> file
>>>>>> will automatically added to all generated jars (but not in assembled
>>>>>> artifacts).
>>>>>> And to leverage automatic *appending* specific LICENSE/NOTICE file
>>>>>> fragments for specific modules which embed 3rd party resources, via
>>>>>> src/main/appended-resources/META-INF/LICENSE and/or ./NOTICE files.
>>>>>>
>>>>>> I'm happy to try help out if this raises questions (and I expect it
>>>>>> will),
>>>>>> but that'll be more practical to do case by case.
>>>>>> Trying to write down such 'guidelines' generically typically just
>> leads
>>>>>> to
>>>>>> more confusion :)
>>>>>>
>>>>>> Kind regards,
>>>>>> Ate
>>>>>>
>>>>>>
>>>>>> On 2015-10-05 22:16, Ian Maxon wrote:
>>>>>>
>>>>>> Hi everyone,
>>>>>>>
>>>>>>> Please verify and vote on the first full Apache AsterixDB release!
>>>>>>> This candidate addresses some of the differences that were noticed
>>>>>>> between the tagged commit in git and the source packaging.
>>>>>>>
>>>>>>> The tag to be voted on is
>>>>>>>
>>>>>>> asterix-0.8.7-incubating
>>>>>>> commit : d2e1e89cfdf39e2b772dff2600913bb79644a380
>>>>>>> link:
>>>>>>>
>>>>>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-asterixdb.git;a=tag;h=refs/tags/asterix-0.8.7-incubating
>>>>>>>
>>>>>>> The artifacts, md5s, and signatures are at:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.asc
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.md5
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.sha1
>>>>>>>
>>>>>>> MD5: 7330e6d6c2dd691ae3ab6a641e4d5344
>>>>>>> SHA1: bf0b4a2ceaa26bcf1fcda33fee1ba227e31a88ba
>>>>>>>
>>>>>>> Additionally, a staged maven repository is available at:
>>>>>>>
>>>>>>>
>>>
>> https://repository.apache.org/content/repositories/orgapacheasterix-1014/
>>>>>>>
>>>>>>> The KEYS file containing the PGP keys used to sign the release can
>> be
>>>>>>> found at
>>>>>>>
>>>>>>> https://dist.apache.org/repos/dist/release/incubator/asterixdb/KEYS
>>>>>>>
>>>>>>> RAT was executed as part of Maven via the RAT maven plugin, as well
>> as
>>>>>>> manually, but it
>>>>>>> excludes the following paths:
>>>>>>>
>>>>>>> .*\.adm
>>>>>>> .*\.aql
>>>>>>> .*\.cleaned
>>>>>>> .*\.csv
>>>>>>> .*\.csv.cr
>>>>>>> .*\.csv.crlf
>>>>>>> .*\.csv.lf
>>>>>>> .*\.ddl
>>>>>>> .*\.dot
>>>>>>> .*\.hcli
>>>>>>> .*\.iml
>>>>>>> .*\.json
>>>>>>> .*\.out
>>>>>>> .*\.plan
>>>>>>> .*\.ps
>>>>>>> .*\.scm
>>>>>>> .*\.tbl
>>>>>>> .*\.tbl\.big
>>>>>>> .*\.tsv
>>>>>>> .*\.txt
>>>>>>> .*large_text
>>>>>>> .*part-00000
>>>>>>> .*part-00001
>>>>>>>
>>>>>>> .*\.goutputstream-YQMB2V
>>>>>>> .*02-fuzzy-select
>>>>>>> .*LockRequestFile
>>>>>>> .*hosts
>>>>>>> .*id_rsa
>>>>>>> .*known_hosts
>>>>>>>
>>>>>>> .*bottle.py
>>>>>>> .*geostats.js
>>>>>>> .*jquery.autosize-min.js
>>>>>>> .*jquery.min.js
>>>>>>> .*rainbowvis.js
>>>>>>> .*smoothie.js
>>>>>>>
>>>>>>>
>>>>>>> These files either are either data for tests, procedurally
>> generated,
>>>>>>> or source files which come without a header mentioning their
>> license,
>>>>>>> but have an explicit reference in the LICENSE file.
>>>>>>>
>>>>>>> The complete RAT report is available at:
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>> https://gist.githubusercontent.com/westmann/b6ed4b25bea44adcd526/raw/be93ff0c1d13c2ce7c88a2b713ace130b5e7ef5f/gistfile1.txt
>>>>>>>
>>>>>>> The vote is open for 72 hours, or until the necessary number of
>> votes
>>>>>>> (3 +1) has been reached.
>>>>>>>
>>>>>>> Please vote
>>>>>>> [ ] +1 release this package as Apache AsterixDB 0.8.7-incubating
>>>>>>> [ ] 0 No strong feeling either way
>>>>>>> [ ] -1 do not release this package because ...
>>>>>>>
>>>>>>> Thanks!
>>>>>>> -Ian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>>
>

Re: [DISCUSS] Release Apache AsterixDB 0.8.7-incubating (RC3)

[Chris Hillery <ch...@hillery.land>]

Could we continue to provide those binary artifacts as "unofficial"
releases via our own website?

Ceej
aka Chris Hillery
On Oct 8, 2015 1:40 PM, "Ian Maxon" <im...@uci.edu> wrote:

> Hm, alright, if that's something that seems valuable, then I'm OK with it.
> I suppose my eyes were set on getting the asterix-installer and
> asterix-yarn packagings out, since that's usually what end-users are
> downloading first. It is true that this has taken a lot longer than I think
> anyone would've liked.
>
> -Ian
>
> On Thu, Oct 8, 2015 at 1:25 PM, Chris Hillery <ch...@hillery.land>
> wrote:
>
> > That sounds like a reasonable idea to me. If Ate is right that this
> usually
> > takes several releases to get correct, it could be a really long time
> > before we have binaries fully ready to go. This release has already taken
> > months longer than expected; let's have a source-only release for now so
> we
> > can continue moving forward.
> >
> > Ceej
> > aka Chris Hillery
> > On Oct 8, 2015 1:15 PM, "Till Westmann" <ti...@apache.org> wrote:
> >
> > > Would it also be an option to
> > > a) release the current release in source-only form,
> > > b) not advertise/distribute the binaries for now, and
> > > c) fix this for the next release?
> > >
> > > Right now we have zero AsterixDB releases at the ASF and that way
> > > we could have one that people have to build on their own (which is
> > > the usual way at the ASF and no rocket science for any developer).
> > > Also, I think that individual developer can still build a binary and
> > > give it to someone for testing, it’s just not an ASF artifact at
> > > that point.
> > >
> > > Thoughts/Concerns?
> > >
> > > Cheers,
> > > Till
> > >
> > >
> > > On 7 Oct 2015, at 15:49, Ian Maxon wrote:
> > >
> > > I see, thank you for the very detailed analysis Ate. I think we will
> have
> > >> to fix all of the binary assemblies to conform.  What's in Maven is
> > >> important, as well as the bundled zips and such. Our usual method of
> > >> distribution to end-users is via those bundled zips, rather than
> source.
> > >> In
> > >> fact we actually had to add the source assembly specifically for
> voting,
> > >> typically developers or folks who need special patches simply check
> out
> > >> from git.
> > >> More info/updates to come as I dig into how to coax maven into doing
> > this
> > >> nicely...
> > >>
> > >> Thanks again,
> > >> -Ian
> > >>
> > >> On Wed, Oct 7, 2015 at 3:24 PM, Ate Douma <at...@douma.nu> wrote:
> > >>
> > >> Hi team,
> > >>>
> > >>> I either can +1 or -1 this release candidate, depending on if the
> > staged
> > >>> maven repository provided artifacts are also intended to be
> > >>> distributed...
> > >>>
> > >>> For just the source release (like for the Hyracks release), I think
> it
> > is
> > >>> good to go, so +1 for that.
> > >>>
> > >>> But for the binary artifacts in the Maven repo, it is definitely a
> -1.
> > >>>
> > >>> So either you'll drop/skip releasing to the Maven repo for this time,
> > and
> > >>> then you might be good (pending possible feedback from others), or
> this
> > >>> vote better be cancelled and prepare for a lot of work to get this
> > fixed
> > >>> first...
> > >>>
> > >>> As I already mentioned on the Hyracks release candidate: LICENSE,
> > NOTICE
> > >>> and DISCLAIMER requirements apply to all released/distributed
> > artifacts.
> > >>> As such, all the build artifacts in the Maven repository also have to
> > >>> contain and provide these...
> > >>> Please check again the requirements for binary (re)distributions
> here:
> > >>>
> > >>>
> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
> > >>> http://www.apache.org/dev/licensing-howto.html#deps-of-deps
> > >>> http://www.apache.org/dev/licensing-howto.html#binary
> > >>>
> > >>> And in general everything on whole page.
> > >>>
> > >>> Some of the Maven repo jars already do have the 'verbatim' Apache
> > LICENSE
> > >>> and NOTICE files, but none provide the Incubator DISCLAIMER, which in
> > >>> addition to the above rules also is required for every distribution
> > from
> > >>> the Incubator.
> > >>>
> > >>> And some others jars don't even bundle a LICENSE and NOTICE file like
> > >>> asterix-common-0.8.7-incubating.jar (there are possibly more, I
> didn't
> > >>> check each and every one).
> > >>>
> > >>> And besides this, aggregating distributions like all .zip|.tar etc.
> > files
> > >>> contain none of these files. Including module -source-release.zip
> files
> > >>> like asterix-events-0.8.7-incubating-source-release.zip and the
> > -demo.zip
> > >>> files.
> > >>>
> > >>> All of these artifacts when released/distributed have to comply to
> the
> > >>> above rules.
> > >>> Which most definitely isn't a trivial task to comply with and
> typically
> > >>> takes several iterations to get right... Painful yes, but necessary.
> > >>> Once setup and configured properly though, thereafter it usually
> > doesn't
> > >>> require a lot of work to keep it up to date.
> > >>>
> > >>> But getting it right the first time will.
> > >>> Just saying so that you'll all be aware this isn't something likely
> > >>> fixable in a few minutes or even hours...
> > >>>
> > >>> Two important things to keep in mind:
> > >>> - LICENSE and NOTICE files must be tailored specifically to the
> > >>> distribution containing them, providing attribution to what the
> > >>> distribution contains, but nothing more.
> > >>> For example 3rd party embedded sources like JQuery require license
> > >>> attribution, but NOT in artifacts NOT embedding them.
> > >>> So the asterix-app should indeed mention this in the LICENSE file in
> > its
> > >>> jar AND -binary-assembly.zip, but for example the asterix-algebra jar
> > >>> should NOT.
> > >>> - Distributions bundling other distributions must aggregate possible
> > >>> LICENSE and NOTICE attributions of those other distributions within
> > their
> > >>> main LICENSE and NOTICE file.
> > >>> So for example, the LICENSE and NOTICE files in the asterix-app
> > >>> binary-assembly.zip must aggregate those from the bundled/embedded
> > >>> asterix-app *jar*.
> > >>> And further more, as the binary-assembly.zip bundles many other,
> > >>> including 3rd party, jars, their LICENSE and/or NOTICE attributions
> > needs
> > >>> to be aggregated as well (when needed, which depends on the
> particular
> > >>> LICENSE and/or NOTICE). Including possible other licenses applicable
> to
> > >>> those bundled jars (or whatever bundled bits).
> > >>> And for aggregates of aggregates, like the asterix-installer
> > >>> binary-assembly.zip, this has to be done 'transitively'. Yeah, a lot
> of
> > >>> work indeed.
> > >>>
> > >>> I also like to refer back to the [DISCUSS] mail I send earlier on the
> > >>> Hyracks release candidate, where I already indicated this to become
> > >>> critical when releasing binary artifacts.
> > >>> And to a few suggestions I gave then like configuring the
> > >>> apache-incubator-disclaimer-resource-bundle to ensure the DISCLAIMER
> > file
> > >>> will automatically added to all generated jars (but not in assembled
> > >>> artifacts).
> > >>> And to leverage automatic *appending* specific LICENSE/NOTICE file
> > >>> fragments for specific modules which embed 3rd party resources, via
> > >>> src/main/appended-resources/META-INF/LICENSE and/or ./NOTICE files.
> > >>>
> > >>> I'm happy to try help out if this raises questions (and I expect it
> > >>> will),
> > >>> but that'll be more practical to do case by case.
> > >>> Trying to write down such 'guidelines' generically typically just
> leads
> > >>> to
> > >>> more confusion :)
> > >>>
> > >>> Kind regards,
> > >>> Ate
> > >>>
> > >>>
> > >>> On 2015-10-05 22:16, Ian Maxon wrote:
> > >>>
> > >>> Hi everyone,
> > >>>>
> > >>>> Please verify and vote on the first full Apache AsterixDB release!
> > >>>> This candidate addresses some of the differences that were noticed
> > >>>> between the tagged commit in git and the source packaging.
> > >>>>
> > >>>> The tag to be voted on is
> > >>>>
> > >>>> asterix-0.8.7-incubating
> > >>>> commit : d2e1e89cfdf39e2b772dff2600913bb79644a380
> > >>>> link:
> > >>>>
> > >>>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-asterixdb.git;a=tag;h=refs/tags/asterix-0.8.7-incubating
> > >>>>
> > >>>> The artifacts, md5s, and signatures are at:
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> >
> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip
> > >>>>
> > >>>>
> > >>>>
> >
> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.asc
> > >>>>
> > >>>>
> > >>>>
> >
> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.md5
> > >>>>
> > >>>>
> > >>>>
> >
> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.sha1
> > >>>>
> > >>>> MD5: 7330e6d6c2dd691ae3ab6a641e4d5344
> > >>>> SHA1: bf0b4a2ceaa26bcf1fcda33fee1ba227e31a88ba
> > >>>>
> > >>>> Additionally, a staged maven repository is available at:
> > >>>>
> > >>>>
> >
> https://repository.apache.org/content/repositories/orgapacheasterix-1014/
> > >>>>
> > >>>> The KEYS file containing the PGP keys used to sign the release can
> be
> > >>>> found at
> > >>>>
> > >>>> https://dist.apache.org/repos/dist/release/incubator/asterixdb/KEYS
> > >>>>
> > >>>> RAT was executed as part of Maven via the RAT maven plugin, as well
> as
> > >>>> manually, but it
> > >>>> excludes the following paths:
> > >>>>
> > >>>> .*\.adm
> > >>>> .*\.aql
> > >>>> .*\.cleaned
> > >>>> .*\.csv
> > >>>> .*\.csv.cr
> > >>>> .*\.csv.crlf
> > >>>> .*\.csv.lf
> > >>>> .*\.ddl
> > >>>> .*\.dot
> > >>>> .*\.hcli
> > >>>> .*\.iml
> > >>>> .*\.json
> > >>>> .*\.out
> > >>>> .*\.plan
> > >>>> .*\.ps
> > >>>> .*\.scm
> > >>>> .*\.tbl
> > >>>> .*\.tbl\.big
> > >>>> .*\.tsv
> > >>>> .*\.txt
> > >>>> .*large_text
> > >>>> .*part-00000
> > >>>> .*part-00001
> > >>>>
> > >>>> .*\.goutputstream-YQMB2V
> > >>>> .*02-fuzzy-select
> > >>>> .*LockRequestFile
> > >>>> .*hosts
> > >>>> .*id_rsa
> > >>>> .*known_hosts
> > >>>>
> > >>>> .*bottle.py
> > >>>> .*geostats.js
> > >>>> .*jquery.autosize-min.js
> > >>>> .*jquery.min.js
> > >>>> .*rainbowvis.js
> > >>>> .*smoothie.js
> > >>>>
> > >>>>
> > >>>> These files either are either data for tests, procedurally
> generated,
> > >>>> or source files which come without a header mentioning their
> license,
> > >>>> but have an explicit reference in the LICENSE file.
> > >>>>
> > >>>> The complete RAT report is available at:
> > >>>>
> > >>>>
> > >>>>
> >
> https://gist.githubusercontent.com/westmann/b6ed4b25bea44adcd526/raw/be93ff0c1d13c2ce7c88a2b713ace130b5e7ef5f/gistfile1.txt
> > >>>>
> > >>>> The vote is open for 72 hours, or until the necessary number of
> votes
> > >>>> (3 +1) has been reached.
> > >>>>
> > >>>> Please vote
> > >>>> [ ] +1 release this package as Apache AsterixDB 0.8.7-incubating
> > >>>> [ ] 0 No strong feeling either way
> > >>>> [ ] -1 do not release this package because ...
> > >>>>
> > >>>> Thanks!
> > >>>> -Ian
> > >>>>
> > >>>>
> > >>>>
> > >>>
> >
>

Re: [DISCUSS] Release Apache AsterixDB 0.8.7-incubating (RC3)

[Ian Maxon <im...@uci.edu>]

Hm, alright, if that's something that seems valuable, then I'm OK with it.
I suppose my eyes were set on getting the asterix-installer and
asterix-yarn packagings out, since that's usually what end-users are
downloading first. It is true that this has taken a lot longer than I think
anyone would've liked.

-Ian

On Thu, Oct 8, 2015 at 1:25 PM, Chris Hillery <ch...@hillery.land> wrote:

> That sounds like a reasonable idea to me. If Ate is right that this usually
> takes several releases to get correct, it could be a really long time
> before we have binaries fully ready to go. This release has already taken
> months longer than expected; let's have a source-only release for now so we
> can continue moving forward.
>
> Ceej
> aka Chris Hillery
> On Oct 8, 2015 1:15 PM, "Till Westmann" <ti...@apache.org> wrote:
>
> > Would it also be an option to
> > a) release the current release in source-only form,
> > b) not advertise/distribute the binaries for now, and
> > c) fix this for the next release?
> >
> > Right now we have zero AsterixDB releases at the ASF and that way
> > we could have one that people have to build on their own (which is
> > the usual way at the ASF and no rocket science for any developer).
> > Also, I think that individual developer can still build a binary and
> > give it to someone for testing, it’s just not an ASF artifact at
> > that point.
> >
> > Thoughts/Concerns?
> >
> > Cheers,
> > Till
> >
> >
> > On 7 Oct 2015, at 15:49, Ian Maxon wrote:
> >
> > I see, thank you for the very detailed analysis Ate. I think we will have
> >> to fix all of the binary assemblies to conform.  What's in Maven is
> >> important, as well as the bundled zips and such. Our usual method of
> >> distribution to end-users is via those bundled zips, rather than source.
> >> In
> >> fact we actually had to add the source assembly specifically for voting,
> >> typically developers or folks who need special patches simply check out
> >> from git.
> >> More info/updates to come as I dig into how to coax maven into doing
> this
> >> nicely...
> >>
> >> Thanks again,
> >> -Ian
> >>
> >> On Wed, Oct 7, 2015 at 3:24 PM, Ate Douma <at...@douma.nu> wrote:
> >>
> >> Hi team,
> >>>
> >>> I either can +1 or -1 this release candidate, depending on if the
> staged
> >>> maven repository provided artifacts are also intended to be
> >>> distributed...
> >>>
> >>> For just the source release (like for the Hyracks release), I think it
> is
> >>> good to go, so +1 for that.
> >>>
> >>> But for the binary artifacts in the Maven repo, it is definitely a -1.
> >>>
> >>> So either you'll drop/skip releasing to the Maven repo for this time,
> and
> >>> then you might be good (pending possible feedback from others), or this
> >>> vote better be cancelled and prepare for a lot of work to get this
> fixed
> >>> first...
> >>>
> >>> As I already mentioned on the Hyracks release candidate: LICENSE,
> NOTICE
> >>> and DISCLAIMER requirements apply to all released/distributed
> artifacts.
> >>> As such, all the build artifacts in the Maven repository also have to
> >>> contain and provide these...
> >>> Please check again the requirements for binary (re)distributions here:
> >>>
> >>> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
> >>> http://www.apache.org/dev/licensing-howto.html#deps-of-deps
> >>> http://www.apache.org/dev/licensing-howto.html#binary
> >>>
> >>> And in general everything on whole page.
> >>>
> >>> Some of the Maven repo jars already do have the 'verbatim' Apache
> LICENSE
> >>> and NOTICE files, but none provide the Incubator DISCLAIMER, which in
> >>> addition to the above rules also is required for every distribution
> from
> >>> the Incubator.
> >>>
> >>> And some others jars don't even bundle a LICENSE and NOTICE file like
> >>> asterix-common-0.8.7-incubating.jar (there are possibly more, I didn't
> >>> check each and every one).
> >>>
> >>> And besides this, aggregating distributions like all .zip|.tar etc.
> files
> >>> contain none of these files. Including module -source-release.zip files
> >>> like asterix-events-0.8.7-incubating-source-release.zip and the
> -demo.zip
> >>> files.
> >>>
> >>> All of these artifacts when released/distributed have to comply to the
> >>> above rules.
> >>> Which most definitely isn't a trivial task to comply with and typically
> >>> takes several iterations to get right... Painful yes, but necessary.
> >>> Once setup and configured properly though, thereafter it usually
> doesn't
> >>> require a lot of work to keep it up to date.
> >>>
> >>> But getting it right the first time will.
> >>> Just saying so that you'll all be aware this isn't something likely
> >>> fixable in a few minutes or even hours...
> >>>
> >>> Two important things to keep in mind:
> >>> - LICENSE and NOTICE files must be tailored specifically to the
> >>> distribution containing them, providing attribution to what the
> >>> distribution contains, but nothing more.
> >>> For example 3rd party embedded sources like JQuery require license
> >>> attribution, but NOT in artifacts NOT embedding them.
> >>> So the asterix-app should indeed mention this in the LICENSE file in
> its
> >>> jar AND -binary-assembly.zip, but for example the asterix-algebra jar
> >>> should NOT.
> >>> - Distributions bundling other distributions must aggregate possible
> >>> LICENSE and NOTICE attributions of those other distributions within
> their
> >>> main LICENSE and NOTICE file.
> >>> So for example, the LICENSE and NOTICE files in the asterix-app
> >>> binary-assembly.zip must aggregate those from the bundled/embedded
> >>> asterix-app *jar*.
> >>> And further more, as the binary-assembly.zip bundles many other,
> >>> including 3rd party, jars, their LICENSE and/or NOTICE attributions
> needs
> >>> to be aggregated as well (when needed, which depends on the particular
> >>> LICENSE and/or NOTICE). Including possible other licenses applicable to
> >>> those bundled jars (or whatever bundled bits).
> >>> And for aggregates of aggregates, like the asterix-installer
> >>> binary-assembly.zip, this has to be done 'transitively'. Yeah, a lot of
> >>> work indeed.
> >>>
> >>> I also like to refer back to the [DISCUSS] mail I send earlier on the
> >>> Hyracks release candidate, where I already indicated this to become
> >>> critical when releasing binary artifacts.
> >>> And to a few suggestions I gave then like configuring the
> >>> apache-incubator-disclaimer-resource-bundle to ensure the DISCLAIMER
> file
> >>> will automatically added to all generated jars (but not in assembled
> >>> artifacts).
> >>> And to leverage automatic *appending* specific LICENSE/NOTICE file
> >>> fragments for specific modules which embed 3rd party resources, via
> >>> src/main/appended-resources/META-INF/LICENSE and/or ./NOTICE files.
> >>>
> >>> I'm happy to try help out if this raises questions (and I expect it
> >>> will),
> >>> but that'll be more practical to do case by case.
> >>> Trying to write down such 'guidelines' generically typically just leads
> >>> to
> >>> more confusion :)
> >>>
> >>> Kind regards,
> >>> Ate
> >>>
> >>>
> >>> On 2015-10-05 22:16, Ian Maxon wrote:
> >>>
> >>> Hi everyone,
> >>>>
> >>>> Please verify and vote on the first full Apache AsterixDB release!
> >>>> This candidate addresses some of the differences that were noticed
> >>>> between the tagged commit in git and the source packaging.
> >>>>
> >>>> The tag to be voted on is
> >>>>
> >>>> asterix-0.8.7-incubating
> >>>> commit : d2e1e89cfdf39e2b772dff2600913bb79644a380
> >>>> link:
> >>>>
> >>>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-asterixdb.git;a=tag;h=refs/tags/asterix-0.8.7-incubating
> >>>>
> >>>> The artifacts, md5s, and signatures are at:
> >>>>
> >>>>
> >>>>
> >>>>
> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip
> >>>>
> >>>>
> >>>>
> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.asc
> >>>>
> >>>>
> >>>>
> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.md5
> >>>>
> >>>>
> >>>>
> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.sha1
> >>>>
> >>>> MD5: 7330e6d6c2dd691ae3ab6a641e4d5344
> >>>> SHA1: bf0b4a2ceaa26bcf1fcda33fee1ba227e31a88ba
> >>>>
> >>>> Additionally, a staged maven repository is available at:
> >>>>
> >>>>
> https://repository.apache.org/content/repositories/orgapacheasterix-1014/
> >>>>
> >>>> The KEYS file containing the PGP keys used to sign the release can be
> >>>> found at
> >>>>
> >>>> https://dist.apache.org/repos/dist/release/incubator/asterixdb/KEYS
> >>>>
> >>>> RAT was executed as part of Maven via the RAT maven plugin, as well as
> >>>> manually, but it
> >>>> excludes the following paths:
> >>>>
> >>>> .*\.adm
> >>>> .*\.aql
> >>>> .*\.cleaned
> >>>> .*\.csv
> >>>> .*\.csv.cr
> >>>> .*\.csv.crlf
> >>>> .*\.csv.lf
> >>>> .*\.ddl
> >>>> .*\.dot
> >>>> .*\.hcli
> >>>> .*\.iml
> >>>> .*\.json
> >>>> .*\.out
> >>>> .*\.plan
> >>>> .*\.ps
> >>>> .*\.scm
> >>>> .*\.tbl
> >>>> .*\.tbl\.big
> >>>> .*\.tsv
> >>>> .*\.txt
> >>>> .*large_text
> >>>> .*part-00000
> >>>> .*part-00001
> >>>>
> >>>> .*\.goutputstream-YQMB2V
> >>>> .*02-fuzzy-select
> >>>> .*LockRequestFile
> >>>> .*hosts
> >>>> .*id_rsa
> >>>> .*known_hosts
> >>>>
> >>>> .*bottle.py
> >>>> .*geostats.js
> >>>> .*jquery.autosize-min.js
> >>>> .*jquery.min.js
> >>>> .*rainbowvis.js
> >>>> .*smoothie.js
> >>>>
> >>>>
> >>>> These files either are either data for tests, procedurally generated,
> >>>> or source files which come without a header mentioning their license,
> >>>> but have an explicit reference in the LICENSE file.
> >>>>
> >>>> The complete RAT report is available at:
> >>>>
> >>>>
> >>>>
> https://gist.githubusercontent.com/westmann/b6ed4b25bea44adcd526/raw/be93ff0c1d13c2ce7c88a2b713ace130b5e7ef5f/gistfile1.txt
> >>>>
> >>>> The vote is open for 72 hours, or until the necessary number of votes
> >>>> (3 +1) has been reached.
> >>>>
> >>>> Please vote
> >>>> [ ] +1 release this package as Apache AsterixDB 0.8.7-incubating
> >>>> [ ] 0 No strong feeling either way
> >>>> [ ] -1 do not release this package because ...
> >>>>
> >>>> Thanks!
> >>>> -Ian
> >>>>
> >>>>
> >>>>
> >>>
>

Re: [DISCUSS] Release Apache AsterixDB 0.8.7-incubating (RC3)

[Chris Hillery <ch...@hillery.land>]

That sounds like a reasonable idea to me. If Ate is right that this usually
takes several releases to get correct, it could be a really long time
before we have binaries fully ready to go. This release has already taken
months longer than expected; let's have a source-only release for now so we
can continue moving forward.

Ceej
aka Chris Hillery
On Oct 8, 2015 1:15 PM, "Till Westmann" <ti...@apache.org> wrote:

> Would it also be an option to
> a) release the current release in source-only form,
> b) not advertise/distribute the binaries for now, and
> c) fix this for the next release?
>
> Right now we have zero AsterixDB releases at the ASF and that way
> we could have one that people have to build on their own (which is
> the usual way at the ASF and no rocket science for any developer).
> Also, I think that individual developer can still build a binary and
> give it to someone for testing, it’s just not an ASF artifact at
> that point.
>
> Thoughts/Concerns?
>
> Cheers,
> Till
>
>
> On 7 Oct 2015, at 15:49, Ian Maxon wrote:
>
> I see, thank you for the very detailed analysis Ate. I think we will have
>> to fix all of the binary assemblies to conform.  What's in Maven is
>> important, as well as the bundled zips and such. Our usual method of
>> distribution to end-users is via those bundled zips, rather than source.
>> In
>> fact we actually had to add the source assembly specifically for voting,
>> typically developers or folks who need special patches simply check out
>> from git.
>> More info/updates to come as I dig into how to coax maven into doing this
>> nicely...
>>
>> Thanks again,
>> -Ian
>>
>> On Wed, Oct 7, 2015 at 3:24 PM, Ate Douma <at...@douma.nu> wrote:
>>
>> Hi team,
>>>
>>> I either can +1 or -1 this release candidate, depending on if the staged
>>> maven repository provided artifacts are also intended to be
>>> distributed...
>>>
>>> For just the source release (like for the Hyracks release), I think it is
>>> good to go, so +1 for that.
>>>
>>> But for the binary artifacts in the Maven repo, it is definitely a -1.
>>>
>>> So either you'll drop/skip releasing to the Maven repo for this time, and
>>> then you might be good (pending possible feedback from others), or this
>>> vote better be cancelled and prepare for a lot of work to get this fixed
>>> first...
>>>
>>> As I already mentioned on the Hyracks release candidate: LICENSE, NOTICE
>>> and DISCLAIMER requirements apply to all released/distributed artifacts.
>>> As such, all the build artifacts in the Maven repository also have to
>>> contain and provide these...
>>> Please check again the requirements for binary (re)distributions here:
>>>
>>> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
>>> http://www.apache.org/dev/licensing-howto.html#deps-of-deps
>>> http://www.apache.org/dev/licensing-howto.html#binary
>>>
>>> And in general everything on whole page.
>>>
>>> Some of the Maven repo jars already do have the 'verbatim' Apache LICENSE
>>> and NOTICE files, but none provide the Incubator DISCLAIMER, which in
>>> addition to the above rules also is required for every distribution from
>>> the Incubator.
>>>
>>> And some others jars don't even bundle a LICENSE and NOTICE file like
>>> asterix-common-0.8.7-incubating.jar (there are possibly more, I didn't
>>> check each and every one).
>>>
>>> And besides this, aggregating distributions like all .zip|.tar etc. files
>>> contain none of these files. Including module -source-release.zip files
>>> like asterix-events-0.8.7-incubating-source-release.zip and the -demo.zip
>>> files.
>>>
>>> All of these artifacts when released/distributed have to comply to the
>>> above rules.
>>> Which most definitely isn't a trivial task to comply with and typically
>>> takes several iterations to get right... Painful yes, but necessary.
>>> Once setup and configured properly though, thereafter it usually doesn't
>>> require a lot of work to keep it up to date.
>>>
>>> But getting it right the first time will.
>>> Just saying so that you'll all be aware this isn't something likely
>>> fixable in a few minutes or even hours...
>>>
>>> Two important things to keep in mind:
>>> - LICENSE and NOTICE files must be tailored specifically to the
>>> distribution containing them, providing attribution to what the
>>> distribution contains, but nothing more.
>>> For example 3rd party embedded sources like JQuery require license
>>> attribution, but NOT in artifacts NOT embedding them.
>>> So the asterix-app should indeed mention this in the LICENSE file in its
>>> jar AND -binary-assembly.zip, but for example the asterix-algebra jar
>>> should NOT.
>>> - Distributions bundling other distributions must aggregate possible
>>> LICENSE and NOTICE attributions of those other distributions within their
>>> main LICENSE and NOTICE file.
>>> So for example, the LICENSE and NOTICE files in the asterix-app
>>> binary-assembly.zip must aggregate those from the bundled/embedded
>>> asterix-app *jar*.
>>> And further more, as the binary-assembly.zip bundles many other,
>>> including 3rd party, jars, their LICENSE and/or NOTICE attributions needs
>>> to be aggregated as well (when needed, which depends on the particular
>>> LICENSE and/or NOTICE). Including possible other licenses applicable to
>>> those bundled jars (or whatever bundled bits).
>>> And for aggregates of aggregates, like the asterix-installer
>>> binary-assembly.zip, this has to be done 'transitively'. Yeah, a lot of
>>> work indeed.
>>>
>>> I also like to refer back to the [DISCUSS] mail I send earlier on the
>>> Hyracks release candidate, where I already indicated this to become
>>> critical when releasing binary artifacts.
>>> And to a few suggestions I gave then like configuring the
>>> apache-incubator-disclaimer-resource-bundle to ensure the DISCLAIMER file
>>> will automatically added to all generated jars (but not in assembled
>>> artifacts).
>>> And to leverage automatic *appending* specific LICENSE/NOTICE file
>>> fragments for specific modules which embed 3rd party resources, via
>>> src/main/appended-resources/META-INF/LICENSE and/or ./NOTICE files.
>>>
>>> I'm happy to try help out if this raises questions (and I expect it
>>> will),
>>> but that'll be more practical to do case by case.
>>> Trying to write down such 'guidelines' generically typically just leads
>>> to
>>> more confusion :)
>>>
>>> Kind regards,
>>> Ate
>>>
>>>
>>> On 2015-10-05 22:16, Ian Maxon wrote:
>>>
>>> Hi everyone,
>>>>
>>>> Please verify and vote on the first full Apache AsterixDB release!
>>>> This candidate addresses some of the differences that were noticed
>>>> between the tagged commit in git and the source packaging.
>>>>
>>>> The tag to be voted on is
>>>>
>>>> asterix-0.8.7-incubating
>>>> commit : d2e1e89cfdf39e2b772dff2600913bb79644a380
>>>> link:
>>>>
>>>> https://git-wip-us.apache.org/repos/asf?p=incubator-asterixdb.git;a=tag;h=refs/tags/asterix-0.8.7-incubating
>>>>
>>>> The artifacts, md5s, and signatures are at:
>>>>
>>>>
>>>>
>>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip
>>>>
>>>>
>>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.asc
>>>>
>>>>
>>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.md5
>>>>
>>>>
>>>> https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.sha1
>>>>
>>>> MD5: 7330e6d6c2dd691ae3ab6a641e4d5344
>>>> SHA1: bf0b4a2ceaa26bcf1fcda33fee1ba227e31a88ba
>>>>
>>>> Additionally, a staged maven repository is available at:
>>>>
>>>> https://repository.apache.org/content/repositories/orgapacheasterix-1014/
>>>>
>>>> The KEYS file containing the PGP keys used to sign the release can be
>>>> found at
>>>>
>>>> https://dist.apache.org/repos/dist/release/incubator/asterixdb/KEYS
>>>>
>>>> RAT was executed as part of Maven via the RAT maven plugin, as well as
>>>> manually, but it
>>>> excludes the following paths:
>>>>
>>>> .*\.adm
>>>> .*\.aql
>>>> .*\.cleaned
>>>> .*\.csv
>>>> .*\.csv.cr
>>>> .*\.csv.crlf
>>>> .*\.csv.lf
>>>> .*\.ddl
>>>> .*\.dot
>>>> .*\.hcli
>>>> .*\.iml
>>>> .*\.json
>>>> .*\.out
>>>> .*\.plan
>>>> .*\.ps
>>>> .*\.scm
>>>> .*\.tbl
>>>> .*\.tbl\.big
>>>> .*\.tsv
>>>> .*\.txt
>>>> .*large_text
>>>> .*part-00000
>>>> .*part-00001
>>>>
>>>> .*\.goutputstream-YQMB2V
>>>> .*02-fuzzy-select
>>>> .*LockRequestFile
>>>> .*hosts
>>>> .*id_rsa
>>>> .*known_hosts
>>>>
>>>> .*bottle.py
>>>> .*geostats.js
>>>> .*jquery.autosize-min.js
>>>> .*jquery.min.js
>>>> .*rainbowvis.js
>>>> .*smoothie.js
>>>>
>>>>
>>>> These files either are either data for tests, procedurally generated,
>>>> or source files which come without a header mentioning their license,
>>>> but have an explicit reference in the LICENSE file.
>>>>
>>>> The complete RAT report is available at:
>>>>
>>>>
>>>> https://gist.githubusercontent.com/westmann/b6ed4b25bea44adcd526/raw/be93ff0c1d13c2ce7c88a2b713ace130b5e7ef5f/gistfile1.txt
>>>>
>>>> The vote is open for 72 hours, or until the necessary number of votes
>>>> (3 +1) has been reached.
>>>>
>>>> Please vote
>>>> [ ] +1 release this package as Apache AsterixDB 0.8.7-incubating
>>>> [ ] 0 No strong feeling either way
>>>> [ ] -1 do not release this package because ...
>>>>
>>>> Thanks!
>>>> -Ian
>>>>
>>>>
>>>>
>>>