[mapguide-internals] MapGuide Open Source 2.1 - where is the
continuous integration system ????
Tom Fukushima
tom.fukushima at autodesk.com
Thu Nov 13 16:00:38 EST 2008
Hi,
Thanks for this, but this still doesn't get me a build. We don't have any infrastructure or anyone who will set this up---it's been talked about it, but nothing has come out of it. I think that what we need is the community to step up and support this in some way. To start with, I think we need to get a list of what needs to be done; then perhaps we can sign people up, and then get some stuff done.
UV, are you able to help with anything? If you've done this before you may already have the list of what we need to do; and that would be a good starting point for an RFC.
Up until now, the Autodesk build team has been donating their time to do this, but they just do not have the time now to do this anymore. That this was going to happen is not news.
Thanks
Tom
-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: Thursday, November 13, 2008 5:56 AM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] MapGuide Open Source 2.1 - where is the continuous integration system ????
Continuous Integration System
<http://en.wikipedia.org/wiki/Continuous_Integration>a term formed by
Martin Fowler
<http://www.martinfowler.com/articles/continuousIntegration.html>
This mail brings up the demand for a proper build environment to support
the community.
In a complex project like this a continuous integration system
consisting of at least a linux and a windows build machine
plus maybe some extra machines running tests seems to be appropriate.
This only requires standard off -the-shelf hardware so we are only
talking about a small hardware budget.
Regarding the current shortcomings in configuration management and
stability of the subversion repository
I am sure that an automated build system would be a major step forward
as it forces some extra and useful discipline on
checking in only functional code into the respository (e.g. creating
locks during major code changes).
This way the state of each build configuration can be tracked continuously
and users have an opportunity to access stable snapshots of the source tree.
I had the opportunity to set up and use such a system for a project as
an architect in an international corporation and I would
never do any serious coding without it anymore. I think it can even be
called state-of-the-art by now.
The benefits for a multi-platform open source project like MGOS with a
very complex code base seem to be quite obvious.
Kind Regards,
UV
senior consultant/architect
Tom Fukushima wrote:
> Hi,
>
> Sorry, I've haven't had a chance to follow up on this.
>
> The MGOS 2.1 code is basically ready to go, but we don't have anyone who can do a build.
>
> Jason asked in an offline email whether I had discussed anything internally with Trevor on moving to a VS installer. I can say that all discussions with Trevor have been on this mailing list.
>
> Tom
>
>
> -----Original Message-----
> From: Tom Fukushima
> Subject: [mapguide-internals] MapGuide Open Source 2.1
>
> I would like to post a MGOS 2.1 beta the week of Oct 20th. This is of
> course contingent on me getting resources from our Autodesk internal
> build team (they are very overloaded right now) to get some builds
> together.
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
More information about the mapguide-internals
mailing list