incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From C├ędric Champeau <cedric.champ...@gmail.com>
Subject Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
Date Wed, 24 Jun 2015 07:31:28 GMT
>
> +1
>
> Personally I think the policy should be clarified such that nightly builds
> MUST only live on ASF infrastructure (whether that be the Nexus SNAPSHOTs
> repo, committer web space etc).  As soon as you start putting them on
> external services like DockerHub then they are potentially widely visible
> to the general public.
>

Please do NOT do this. The policy is already painful enough. I can
understand why SOURCES must live
under the Apache organization infrastructure, because they are the ONLY
thing that legal cares about, but
please, for the sake of my mental sanity, do NOT impose any kind of
arbitrary rules like this for binaries/
distribution. It's total madness. Projects like Groovy have been using a
well working infrastructure for a
long time: snapshots published on a snapshot repository, releases pushed
onto Bintray, and we have good reasons
to do this. Our community *loves* to test snapshots, and they are not
stupid. They know that testing something
which is NOT an official release gives no guarantee whatsoever. I think we
should trust our community, and
not try to impose some kind of arbitrary process for the sake of having a
process.

I see no reason why one would like to impose using something like Nexus, it
should be the choice
of each project like it is today. Binaries/distributions are a convenience
and official releases *must* stay sources. For
anything else, it should be up to the project to decide.

I echo what Jochen said already: the move is towards continuous
integration. There's technically no difference between
a snapshot and a release. Apache makes it clear that some releases are
official and that an official release means that
sources for that release are voted and stamped as compliant. That's more
than enough. Toolchains, release process,
how we make binaries/distributions available for testing to our community
should remain under control of the project.

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