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" <[email protected]> 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 <[email protected]>
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" <[email protected]> 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 <[email protected]> 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
