Re: [ASFCS40] Specifically what should be our "binary distribution"?

[Noah Slater <ns...@tumbolia.org>]

Thanks! (A bit late responding, I know!)

Can I just clarify that we're no longer planning to bundle DEB/RPM packages
into our source release?

Thanks,

On Sat, Sep 8, 2012 at 7:09 PM, Chip Childers <ch...@sungard.com>wrote:

> Noah,
>
> First, welcome to the community!
>
> Obviously we are still finding our way on how to get RM activities
> working correctly.  I completely understand (and agree with) the
> intent to have the release manager be able to produce all artifacts
> from a single command (or set of commands...  but I like having one!).
>  Right now, I'm using the script tools/build/build_asf.sh as the
> starting point to achieve this.
>
> The challenge we have right now, is that we wanted to start allowing
> the test engineers participating in the community to help test the
> functionality of the software.  As you can imagine, it's a project
> who's primary purpose drives a ton of integration testing with various
> hardware and software systems.  To that end, Edison got the
> jenkins.cloudstack.org server to produce the required RPM and DEB
> package bundles via a build process against our release branch.  I've
> combined the build artifacts from that source with the results of the
> build_asf.sh script and signed all artifacts.  I then posted them to
> p.a.o/~chipchilders/cloudstack/4.0 as a sample of the eventual results
> we want to release.
>
> Concurrent with that testing I noted above, we're trying to sort out
> how to best deal with the mechanics of doing the release process.  I
> believe I have the source process ironed out (but wouldn't mind
> another set of eyes on the build_asf.sh script).  What's left are the
> binary distributions.
>
> The way that CloudStack had previously been distributed in "binary
> form" from Citrix is actually quite good from a user's standpoint (IMO
> as a user), and we seem to all be in continual agreement that a good
> installation process remains a community priority.  To that end, we
> have several outstanding issues to work through (see [1], [2] and
> [3]), as well as all of the QA time being spent auditing and
> correcting dependency and source code licensing issues.  That being
> said, we have also agreed that we expect the linux distro packaging
> community to create their own packages from the source (and they would
> probably use the sample spec and deb files to help them with that).
> This doesn't, however, mean that we don't want to offer "connivence
> builds" for the agreed upon target OS's [4].
>
> So the question is (given that I too would like to see a single
> command to build everything that we call a release) - are there tools
> that allow us to simultaneously build RPMs and Debian packages on a
> single system?  I haven't found one, but would LOVE if someone had an
> idea there.  Until we can do that though, I think that using the same
> script that jenkins.c.o uses on local VMs that the release manager
> controls will have to be the primary method of creating the release
> binaries.
>
> Thoughts?
>
> -chip
>
> [1] - https://issues.apache.org/jira/browse/CLOUDSTACK-41
> [2] - https://issues.apache.org/jira/browse/CLOUDSTACK-42
> [3] - https://issues.apache.org/jira/browse/CLOUDSTACK-44
> [4] -
> http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201208.mbox/%3C501A7954.8020604%40widodh.nl%3E
>
> On Sat, Sep 8, 2012 at 12:54 PM, Noah Slater <ns...@tumbolia.org> wrote:
> > Hmm. Just reading through the ASF Maven stuff. There's a good chance this
> > takes care of things for you. Excuse my rashness. My release management
> > experience at Apache comes from Autotools, and not Java. The policy (or
> > theory behind it) is the same, but the practicalities of it obviously are
> > not.
> >
> > On Sat, Sep 8, 2012 at 5:44 PM, Noah Slater <ns...@tumbolia.org>
> wrote:
> >
> >> Chip,
> >>
> >> If we're shipping binary distribution artefacts, there needs to a be a
> >> single (preferably) command (or set of commands) (that are well
> documented)
> >> that a user could run that will produce the bit for bit identical file
> or
> >> files. Is this currently the case?
> >>
> >> If it is, then this command should (preferably) be the same command that
> >> the release manager uses, before signing, and uploading to p.a.o. (With
> >> CouchDB, we have a signing step integrated into Autotools. Perhaps some
> >> similar thing might be possible for CloudStack.)
> >>
> >> Thanks,
> >>
> >>
> >> On Fri, Sep 7, 2012 at 1:35 AM, Chip Childers <
> chip.childers@sungard.com>wrote:
> >>
> >>> On Thu, Sep 6, 2012 at 7:40 PM, Edison Su <Ed...@citrix.com>
> wrote:
> >>> >
> >>> >
> >>> >> -----Original Message-----
> >>> >> From: Chip Childers [mailto:chip.childers@sungard.com]
> >>> >> Sent: Thursday, September 06, 2012 1:56 PM
> >>> >> To: cloudstack-dev@incubator.apache.org
> >>> >> Subject: Re: [ASFCS40] Specifically what should be our "binary
> >>> >> distribution"?
> >>> >>
> >>> >> On Thu, Sep 6, 2012 at 4:46 PM, Wido den Hollander <wi...@widodh.nl>
> >>> >> wrote:
> >>> >> >
> >>> >> >
> >>> >> > On 09/06/2012 09:56 PM, Chip Childers wrote:
> >>> >> >>
> >>> >> >> On Thu, Sep 6, 2012 at 3:44 PM, Joe Brockmeier <jz...@zonker.net>
> >>> >> wrote:
> >>> >> >>>
> >>> >> >>> On Thu, Sep 6, 2012, at 02:19 PM, Chip Childers wrote:
> >>> >> >>>>
> >>> >> >>>> Hi all,
> >>> >> >>>>
> >>> >> >>>> Looking at previous CloudStack releases on sourceforge, I see
> that
> >>> >> the
> >>> >> >>>> "binary" distributions are tar.gz rpm/deb packages for RHEL and
> >>> >> >>>> Ubuntu.  I've looked at other Apache projects, and I see that
> they
> >>> >> >>>> usually include the built jar files as their "binary" release
> >>> >> >>>> artifacts.
> >>> >> >>>>
> >>> >> >>>> So my question for everyone is, what specifically do you think
> we
> >>> >> >>>> should be distributing as an RC (and eventually as a release)?
>  Do
> >>> >> we
> >>> >> >>>> want to do a set of the jar files in a tar.gz archive?  Do we
> want
> >>> >> to
> >>> >> >>>> do RPM and DEV packages?  Do we want both?
> >>> >> >>>
> >>> >> >>>
> >>> >> >>> How useful are a set of .jar packages in a tarball?
> >>> >> >>>
> >>> >> >>> Ideally, we can provide something that lets people get set up
> in as
> >>> >> few
> >>> >> >>> steps as possible.
> >>> >> >>
> >>> >> >>
> >>> >> >> Agreed - I was raising the question, but I don't think it's
> needed
> >>> >> or
> >>> >> >> useful.
> >>> >> >>
> >>> >> >>>> If we do the RPM and DEB packages, what OS should we be
> building
> >>> >> on for
> >>> >> >>>> each?
> >>> >> >>>
> >>> >> >>>
> >>> >> >>> At a minimum, the latest RHEL/CentOS and Ubuntu LTS.
> >>> >> >>
> >>> >> >>
> >>> >> >> OK - So should we agree specifically on building on CentOS 6.3
> and
> >>> >> Ubuntu
> >>> >> >> 12.04?
> >>> >> >>
> >>> >> >
> >>> >> > This was already discussed about a month ago:
> >>> >> > http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-
> >>> >> dev/201208.mbox/%3C501A7954.8020604%40widodh.nl%3E
> >>> >> >
> >>> >> > We came to the conclusion:
> >>> >> >
> >>> >> > - Ubuntu 12.04
> >>> >> > - CentOS/RHEL 6.2 and 6.3
> >>> >> >
> >>> >> > I still think our binary distribution should be in the form of RPM
> >>> >> and DEB
> >>> >> > files, that makes life for admins so much easier.
> >>> >>
> >>> >> Right, OK on that.  For this first RC, I'm going to use CentOS 6.2
> and
> >>> >> 6.3.
> >>> >>
> >>> >> I'm also able to easily do Ubuntu 12.04, but I haven't tested the
> >>> >> ./waf deb process yet.  Do you know if the deb build is working
> right
> >>> >> now?
> >>> >>
> >>> >> > I'll be setting up a Debian/Ubuntu repository soon for at the
> Debian
> >>> >> > packages.
> >>> >>
> >>> >> So I think that's great, but I also would like us to release the
> final
> >>> >> 4.0 RPMs and DEBs via the ASF mirrors.  Perhaps similar to the
> >>> >> previous sourceforge packaging structure?
> >>> >>
> >>> >> Does anyone know where the install.sh that was included with the
> >>> >> Citrix cloudstack distro lives?  Is there a packaging process to
> >>> >> create that tarball?
> >>> >
> >>> > Here it is our internal build system:
> >>> https://github.com/CloudStack/hudsonbuild
> >>> > Which can build debs/rpms. I am trying to integrate it with
> >>> http://jenkins.cloudstack.org/
> >>>
> >>> Great!  So if that's the case, then I'm proposing that the release
> >>> process use the build artifacts from http://jenkins.cloudstack.org/
> >>> build jobs for each target OS (to provide the bundled installer
> >>> package) as the binary distros.
> >>>
> >>> I'll still follow the process of using local bundling for the source
> >>> release, since there are lots of notes in the ASF release
> >>> documentation about NOT doing the release signing on ASF
> >>> infrastructure.  I'm assuming that the spirit of those comments is to
> >>> protect the integrity of a source packaging and signing process by not
> >>> allowing them to occur on public / shared systems.
> >>>
> >>> I'll also assume that the artifacts produces by Jenkins still have to
> >>> be signed locally after being downloaded from the Jenkins server.
> >>>
> >>> Please shout if there are disagreements!
> >>>
> >>> >>
> >>> >>
> >>> >>
> >>> >> >>> (Long term we need to focus on being included with the distros,
> but
> >>> >> >>> that's a different discussion.)
> >>> >> >>>
> >>> >> >
> >>> >> > These are the platforms we build binaries for, not the platforms
> it's
> >>> >> only
> >>> >> > going to work on.
> >>> >> >
> >>> >> >
> >>> >> >>>> I know these questions might be obvious to some people, but I
> >>> >> wanted
> >>> >> >>>> to get a clear consensus from the list.
> >>> >> >>>
> >>> >> >>>
> >>> >> >>> Thanks!
> >>> >> >>> --
> >>> >> >>> Joe Brockmeier
> >>> >> >>> jzb@zonker.net
> >>> >> >>> Twitter: @jzb
> >>> >> >>> http://www.dissociatedpress.net/
> >>> >> >>>
> >>> >> >
> >>> >
> >>>
> >>
> >>
> >>
> >> --
> >> NS
> >>
> >
> >
> >
> > --
> > NS
>



-- 
NS