[mapguide-internals] MapGuide Open Source 2.1 - where is thecontinuous integration system ????

[Trevor Wekel]

Perhaps Tim can chime in here but there may be a few holes with simply using the existing build/install scripts for open source:

Autodesk uses BuildForge internally and OsGeo is using BuildBot.  The existing build scripts may not be BuildBot compatible.   The open source community may need to adapt/modify the existing BuildForge scripts to work with BuildBot.

The Windows installers for open source use InstallShield.  Unless someone wants to purchase one or more InstallShield licenses, we will not be able to use the existing open source installers.  I have suggested using Visual Studio deployment projects as an alternative.  I took a brief look at the Visual Studio deployment projects a while ago and they seemed to have enough features.

Tim already has RPM configuration files available for RedHat Linux.  It may be possible to adapt these for use with other distributions.


If we want to get the open source builds moving on Windows, here is an initial set of tasks:

1.  Set up a publically accessible Windows build machine with Visual Studio installed

I should be able to do this by early next week.  However, there is a restriction.  Visual Studio is licensed by user so maintainers should purchase their own copy of Visual Studio Standard (or higher).  Ideally we should use the "build" machine as a build machine and not an installer development box.

http://download.microsoft.com/documents/useterms/Visual%20Studio_2008%20Standard%20Edition_English_4c240268-8ee9-4cf3-96cf-3bd5ef02a81f.pdf
Item 1 b) specifically states "per user"

2.  Obtain the current open source Windows build scripts from Tim and investigate whether they are  appropriate for BuildBot.

3.  Start looking at installer technology for the Windows builds.  The Server install will be easier than the Web Extensions install.  Visual Studio may be sufficient.  InstallShield would be a more expensive option but is guaranteed to work.  As far as I know, InstallShield is also a user based license.

Anyone interested in looking into items 2 or 3?  We can add additional items for the Linux distros (cmake, rpm config files, etc) but I will not have time to set up multiple VMs by next week.  I suspect the community would prefer to see the Windows installs working before we tackle the various Linux distros.

Thanks,
Trevor


________________________________________
From: mapguide-internals-bounces at lists.osgeo.org [mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Tom Fukushima
Sent: Thursday, November 13, 2008 4:03 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] MapGuide Open Source 2.1 - where is   thecontinuous integration system ????

Hi Jason,

Comments inline...

Tom



-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Thursday, November 13, 2008 3:20 PM
To: mapguide-internals at lists.osgeo.org
Subject: Re: [mapguide-internals] MapGuide Open Source 2.1 - where is thecontinuous integration system ????

Tom,

We should be careful to distinguish between continuous builds (a development tool) and packaging (a user service). IMHO, packaging is a much more critical issue at this point.
>>> Continuous builds or builds of some sort are required for the packaging.  The two are required and if we are going to do builds, we should just do it right.  What's to be careful about here, let's set out what needs to be done (RFC), and do it.


Autodesk's resourcing issues had come up a couple times, but the potential disavowal of responsibility for packaging is news to me, and I would imagine most of the users on the public mailing lists.
>>> The build team here does all parts of the build and this includes packaging.

I think that by keeping the installer process closed source, Autodesk essentially committed to maintain the open source installer packages right from the start. Without installers you may have an open source application, but no chance of building a project/community.
>>> There is nothing being kept intentionally under wraps here.  Tim has always told me he's ready to give the scripts to anyone who needs them.

The mgos community may be strong enough to take on the challenge at this point, but I feel that some support from Autodesk (even if its just a list of files, registry keys, conf file setting, permissions, etc) is critical to moving the packaging process out as a community responsibility. I don't have the visual studio expertise to create the setup project, but I would be happy to take on the role of package creation for new MGOS releases if I can get some help setting this up.
>>> I would hope the community can take this on.  It's been over two years since our first release.  Scripts are available from Autodesk.

I don't know what to do about Linux packaging.  Without the adoption of the cmake build process, I have absolutely no interest in even looking at this.
>>> We have never packaged for Linux.  We've only provided the source tar package for that particular release.  It would be good to address this as well.

Jason