asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <dtab...@gmail.com>
Subject Re: [DISCUSS] Release Apache AsterixDB 0.8.7-incubating (RC3)
Date Fri, 09 Oct 2015 15:13:54 GMT
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" <ate@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" <imaxon@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 <chillery@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" <tillw@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 <ate@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>
>>
>
>

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