incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@citrix.com>
Subject RE: [ASFCS40][DISCUSS] Binary packaging - another round of discussions that I'd like us to come to a conclusion on.
Date Tue, 02 Oct 2012 08:14:26 GMT
Moving binary packaging discussion with Noah from another thread here;

>Just a clarification here. It is fine to use, or depend on proprietary
>software that exists on the system. During the build, or after install.
>"For example, using a GPL'ed tool during the build is OK." [1] The
>stipulation is that we cannot ship anything WITH the build that is
>incompatible with our license.
>
>[1] http://www.apache.org/legal/resolved.html

Thanks Noah, so if we build CloudStack against nonoss deps/libs (on non-ASF infra, not likely
but if possible on ASF infra) and publish the binary (which won't have any non ASF compliant
libs/deps/artifacts) on ASF infra that will work?
Only the plugins (which are all ASF compliant) are linked against these nonoss libs.
If we do this, we won't have to do separate builds, nonoss/oss, less trouble for QA and a
user will be just required to install nonoss libs/deps to have the plugins work.

Let's do this?

Regards.

________________________________________
From: Noah Slater [nslater@tumbolia.org]
Sent: Sunday, September 30, 2012 11:10 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [ASFCS40][DISCUSS] Binary packaging - another round of discussions that I'd like
us to come to a conclusion on.

This all sounds good to me.

What would be the difference between the src.tar.gz and the jar one?

On Wed, Sep 12, 2012 at 8:55 PM, Chip Childers <chip.childers@sungard.com>wrote:

> All,
>
> This is another issue that we need to come to a consensus on (and I
> think we can do lazy consensus if required here) prior to 4.0 being
> released.
>
> We've variously been discussing how to best provide binary artifacts
> from the 4.0 release.  Knowing that we are purely discussing
> convenience builds for users, and that ASF releases are source only,
> I'd like to propose the following approach.
>
> I propose that the project only publishes source tarballs to the ASF
> mirrors, and that we rely on the community at large to publish binary
> build artifacts.
>
> Wido has volunteered to host deb and rpm repos containing packages
> built from the source, and I know that (over time) we will see the
> actual distributions put cloudstack packages together.  I would
> imagine (and am not speaking for Wido), that we could work with Wido
> to ensure that his hosted repos have the latest release in them.  We
> would then be in a position where it's OK if a specific distro
> packaging community is a version or two behind the ASF releases.  That
> scenario would allow us to point users that want the very latest
> release to the custom repo, but folks that want official distro
> packages can simply use the version being provided by their OS's
> packaging system.
>
> For the convenience of the community, I'd further propose that we
> provide a set of links to these community repos on our download page
> (including appropriate verbiage about the URLs not representing
> official ASF release artifacts).  This would also include instructions
> for how to setup a RHEL/CentOS/Ubuntu system to pull from Wido's
> hosted repos.
>
> As for QA teams involved in the testing of ASF releases, I believe
> that we should continue to use jenkins.c.o (with Citrix's agreement
> and continued support) as the source for downloading packages for
> testing.  This is because it can do it for us on a nightly schedule.
>
> There is one optional part of this proposal:  we include a tarball of
> cloudstack jar files on the ASF mirrors.  Although, I'm just not sure
> what value that provides to the community.
>
> Thoughts?
>
> -chip
>



--
NS

Mime
View raw message