Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <50EEFA73.3040409@suse.com>
Date: Thu, 10 Jan 2013 12:29:23 -0500
From: Robert Schweikert <rjschwei@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS] Getting CloudStack into the linux distros?
References: 
 <CA+96GG7XyC90Ymt9ZVofOZ6NT2HkrapwDtcB3WXjeHbw8b77mA@mail.gmail.com>
 <50EED227.1080906@widodh.nl>
 <B1DF26ECC0458748AC97CECE2DA98D41012FA3B298F3@SJCPMAILBOX01.citrite.net>
In-Reply-To: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA3B298F3@SJCPMAILBOX01.citrite.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 01/10/2013 11:49 AM, Alex Huang wrote:
> Wido's concern is important.  Some history and how these things have unintended side effects.
>
> Waf was originally developed so that we can get CloudStack packaged into rpms so that cloudstack can get into linux distros.  Waf has quite a few unintended side effects.  The biggest being that it became the only piece of code that can determine the rpms built from cloudstack.  It causes everyone to stop breaking cloudstack further into more jars and packages because no one else knew how to build an rpm from that jar file which then leads to plugins being written inside server jar and can access cloudstack internal code, the current mess we are trying to deal with.  Using waf is the single worst decision we made in CloudStack.  At the time, we just couldn't see how a build system can actually cause such problems in architecture.  Lesson learned.
>
> So if getting into distros means that again, I will be all against it.

Well it doesn't. The decision to build a build system around RPM 
generation was, as you already stated a bad decision. What the project 
needs to worry about, is to have:

- a build system that just builds the code, i.e. create the jar, war,
   whatever files
- a build system that puts the code in the "right places" i.e. where
   the code is expected to be found. This install step has to be
   parametrized such that I can give it a top level directory that
   functions as the "root" location, i.e. everything will be install
   under the directory that I specify.
- documentation as outlined in my previous e-mail

Once the code base fulfills these 3 requirements packaging for a distro 
will be mostly trivial, and you will find people that are willing to do 
the packaging.

Later,
Robert


-- 
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147