[mapguide-internals] RE: [fdo-internals] Hosting FDO 3.5 builds / Binaries for CentOS and Ubuntu

[Greg Boone]

Creating an "build" and/or an "install" directory sounds fine, as does creating a ticket to track the changes.

As for attaching the files, I am sure people can do the review once the files are checked in.

Greg

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
Sent: Friday, February 19, 2010 2:17 PM
To: FDO Internals Mail List
Subject: RE: [mapguide-internals] RE: [fdo-internals] Hosting FDO 3.5 builds / Binaries for CentOS and Ubuntu

Hi Greg,

I have some build/support scripts for creating Ubuntu .deb files almost ready to go.  The scripts automatically generate the file lists for the core Fdo libraries and the various providers.  These file lists are then fed to another set of scripts which create Ubuntu "deb" packages.

Currently, I have the scripts sitting under a "build" directory.  The scripts also create temporary directories for package building in the same place.  I would like to check all of these scripts into Subversion.  There are a total of four core scripts and a few helper scripts.

Can I create an "install" folder at the root of the Fdo 3.5.0 tree to house the scripts?  I can attach the scripts to a Ticket before submitting if someone wants to review a whole bunch of bash trickiness before I submit.

Regards,
Trevor

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: February 19, 2010 10:00 AM
To: FDO Internals Mail List
Subject: RE: [mapguide-internals] RE: [fdo-internals] Hosting FDO 3.5 builds / Binaries for CentOS and Ubuntu

Hi Jason,

I am hesitant to make this change to the 3.5.0 code stream for a number of reasons:


1)      A beta was posted to the downloads site and I am working on an RC. Hopefully one will be posted next week

a.       I do expect that the RC and possibly the final release build will be complete before all the bugs are worked out of this new centralized build and install process.

b.      I guess I am generally being cautious here. I prefer to stick with what we know works instead of trying to fit it in with possible unknown side effects.

2)      We actually have build and runtime code that uses /usr/local/fdo-3.5.0 as a default install location. If we change this to another directory, we should perform additional testing to determine if we have not broken anything

3)      We have clients that have done extensive testing with 3.5.0 using the /usr/local/fdo-3.5.0 directory as a default. I would not want them to be asked to redo that testing at this stage in the release cycle.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20100219/a71be7f1/attachment-0001.html