*nix code-base import and development process
Rodney Degracia
with what you think.
Phase 1: Code-base import and target *nix compilation verification
1) clan-sy releases a version of Spring code-base
2) that code base will be imported into at least two build-boxes: the
latest Debian Stable and the latest Ubuntu Major Release
3) that code base compiled for our target versions of Ubuntu and
Debian, if compilation fails, we report to clan-sy developers that
the compilation failed, along with any errors
Phase 2: Patching to support compilation on OS X
1) If compilation is successful, then our patches would be applied to
the source code of Spring, to allow for Spring to compile on OS X.
2) The patched Spring source is imported into OS X build-boxes and
compilation verified, if compilation fails then the Mac developers
work on fixing the patch code
Phase 3: Back-porting OS X patches, so they don' break *nix builds,
for our target versions of Unbuntu and Debian
1) The patches are then back-ported to our *nix build-boxes and fixed
so they don't break the linux (tactical use of #define and #ifdef)
Phase 4: Submission of patches to clan-sy developers
1) If the back-ported patches are verified to work, then they are
submitted to the clan-sy developers, to be integrated into the main
Spring code-base.
AF
process if possible. I also think tis best we get a mac os x build
slave for the spring build server up and runnign as soon as possible.
Rodney Degracia
external libraries and code-bases that can change with little advanced
notice. Developing in such an environment requires a specific and well
defined development process.
In a nutshell, there are three different external forces that will
affect how we develop code:
1) Clan-SY developer releasing a new Spring build
2) Ubuntu/Debian releasing a new distribution version
3) Apple updating XCode and its headers/libraries
The purpose of the four phase system, outlined below, is to handle
each of the three cases above and minimize the amount of work we need
to do to keep up with any changes from the above.
The purpose of Phase 1, is to standardize on stable Debian (Etch) and
the last Major release number of Ubuntu (8.0 workstation) therefore we
will ensure that we have a stable target linux platform with stable
development libraries. We report any compilation errors to Clan-SY
developers. (In the future, there would be two sets of each
Distribution that we would target: one set for stable Etch/Ubuntu-
major and the other set of machines would be unstable-Etch/Ubuntu-
current)
The purpose of Phase 2, is to allow us to create OS X specific
patches, which we will apply to the Spring source that passes Phase
1. Phase 2 will also allow us a create/test/debug cycle of our OS-X
specific patches onto OS X build boxes (as well as our own XCode
instanace on our iMacs or MacBook Pro laptops).
The purpose of Phase 3, is to allow us to back-port our OS X specific
patches to stable Debian and Major Ubuntu, to verify that our OS-X
specific patches are also Linux compatible. Phase 3 also allows us a
test/debug cycle for our back-ported OS-X patches.
The purpose of Phase 4, is to finally submit our patches (verified in
Phase 3) to Clan-SY developers for inclusion into the main source trunk.
So basically:
Phase 1 handles the case of Debian or Ubuntu distribution upgrades
Phase 2 handles the case of Apple updating XCode and its headers
Phase 3 makes sure that our patches are also friendly to Linux
(enhancing our reputation)
Phase 4 allows us to submit patches that we know are OS X and Linux
compatible
If we implement all four Phases, we will effectively be modifying the
Spring source trunk, to support OS X, in a controllable and stable
manner.
I think if we just simply modify the Spring svn directly, we will not
be developing in a controlled manner and indeed any changes in *nix
distributions, XCode updates by Apple, or Clan-Sy updates will serious
affect the stability of our patches.
Please reply with what you think?
Sharkey
Rodney Degracia
I reread your e-mail and I think I initially misunderstood what you
were suggesting. My understanding now, is that you are suggesting that
we use SVN. If that is the case, I agree with you. I think using SVN
would help with maintaining our patches' source code in a safe manner.
In regards to a Mac OS X 'build slave', I agree that would be
especially needed in Phase 2.2. Build environments must be kept
'clean' and only contain the necessary dependencies required to build
Spring; this means a build environment will be exclusively used to
build (not used for anything else) and should essentially be an OEM
installed Apple environment with the latest patches from Apple and the
latest XCode installed. Unfortunately, at this time I only have a
MacBook Pro and I don't have a spare intel Mac to use as a build-slave.
Sharkey
On Nov 7, 2008, at 11:05 AM, AF wrote: