Hi Fred,
Yes, that is the plan, and as it was
before. Most of the preview fixes we get from I-builds do not break us
backward, so we don’t always need to hold fixes until the end of an
iteration. In this last cycle, this happened quite a bit, but it’s not
been the norm. If it does present a problem, we can always agree to move
forward when necessary.
Another aspect of our nightly build is
that we run a nightly integration as well. So, both a stable config and an integration
config are used to build, and therefore gives us a feel for where we are w.r.t.
both configurations every day.
So, in summary the build plan would be:
-
continuous
builds using latest from HEAD with stable configuration (all dependencies at
last stable “M” build)
-
nightly
builds using latest from HEAD with last integration configuration (all
dependencies at last “I” build, updated weekly)
-
nightly
builds using latest from HEAD with last stable configuration
-
weekly
integration builds (all dependencies at last “I” build)
If the need arises due to breaking changes
that would prevent continuous and nightly builds from functioning, we can agree
to move our dev targets forward to the required configuration. Otherwise, we
would update our dev targets to the latest stable configurations with our
dependency “M” builds (every 6 weeks or so).
Best,
Rich
From:
gmf-dev-bounces@xxxxxxxxxxx [mailto:gmf-dev-bounces@xxxxxxxxxxx] On Behalf Of Frederic Plante
Sent: Wednesday, March 01, 2006
4:54 PM
To: GMF
Project developer discussions.
Cc: GMF
Project developer discussions.; gmf-dev-bounces@xxxxxxxxxxx
Subject: RE: [gmf-dev] Build
I20060227-1730 posted
Hi Rich,
Before
I respond, please confirm I get your proposal right:
GMF
N-builds should be built against its dependencies' S-Build and GMF I-Builds
should be built against its dependencies' I-Builds. The benefit being we can
"learn" about problems early from the I-Build, fix locally and
deliver at the end of the milestone. The drawback being we may very well have
broken I-Builds until the end of the milestone; at which point GMF N-Build
adopts our dependencies' latest S-Build so we can commit the fixes.
Thanks
- Fred
_________________________________
Frédéric Plante
Rational Software, IBM Software Group
"Richard Gronback"
<Richard.Gronback@xxxxxxxxxxx>
Sent
by: gmf-dev-bounces@xxxxxxxxxxx
03/01/2006 03:39 PM
Please
respond to
"GMF Project developer discussions."
|
|
To
|
"GMF Project
developer discussions." <gmf-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [gmf-dev] Build I20060227-1730 posted
|
|
Hi Anthony,
Perhaps we have a difference of opinion regarding the purpose
of Integration builds? Milestone builds are more of an interest to
clients than Integration builds, imo. Integration builds are what allow
us to produce stable Milestone builds by giving us a chance to adjust to
changes in our dependencies. The week before a Milestone build, like this
week, enables us to update our dev targets to the next stable configuration as
we approach our Milestone build. So, we in effect have a week to “kick
the tires” using this config before we release the Milestone. For
the 1.0 Release build, we will have a longer period to do so before producing
the build.
To do this with greater frequency is certainly possible, and
is what we have been doing for the past few weeks. The only difference
being that you are proposing we delay the actual release of the I-build itself
by one week, effectively releasing an Integration build as a mini-milestone
with 1 week periodicity. This seems excessive, to me (while it is actually
easier to configure the build machine this way).
Does anyone else have an opinion on this, or am I missing the
point?
Thanks,
Rich
From:
gmf-dev-bounces@xxxxxxxxxxx [mailto:gmf-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Hunter
Sent: Wednesday, March 01, 2006 1:46 PM
To: GMF Project developer discussions.
Subject: RE: [gmf-dev] Build I20060227-1730 posted
Hi Richard,
I have the opposite opinion in that if our clients are downloading integration drivers,
then I want to be on these targets "kicking the tires" before they
are.
So if we move the weekly I-build to a configuration, then I want that
configuration too.
"doesn’t force us to fix weekly
I-build breakages immediately". So we do not automatically
push these drivers to our clients?
Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Manager - Software Developer,
IBM Rational Software: Aurora Core Common / Modeling Tools
Phone: 613-591-7037
"Richard Gronback"
<Richard.Gronback@xxxxxxxxxxx>
Sent by: gmf-dev-bounces@xxxxxxxxxxx
03/01/2006 07:26 AM
Please
respond to
"GMF Project developer discussions."
<gmf-dev@xxxxxxxxxxx>
|
|
To
|
"GMF Project
developer discussions." <gmf-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [gmf-dev] Build I20060227-1730 posted
|
|
Hi Anthony,
I think you lost me. Currently, we configure a new target weekly
(typically Thursday) that is made up of Platform/EMF/GEF/EMFT weekly I-builds.
Once built, we all move to this target configuration (this was agreed to
for the M5 period).
Previously, we had a stable (last milestone of each) target used for nightly
and continuous builds, with a weekly I-build that used the config mentioned
above. We also ran a nightly build using the I-build config.
I’d recommend we move back to the previous schedule, which allows for a
more stable dev target and doesn’t force us to fix weekly I-build
breakages immediately.
Thanks,
Rich
From: gmf-dev-bounces@xxxxxxxxxxx
[mailto:gmf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Anthony Hunter
Sent: Tuesday, February 28, 2006 11:40 AM
To: GMF Project developer discussions.
Subject: Re: [gmf-dev] Build I20060227-1730 posted
Hi Richard,
Currently:
Eclipse declares a new Integration build for the week we adopt the latest
integration builds for Eclipse + EMF + GEF + EMFT (not 100% sure which day this
is done, but I think it is Thursday).
Once we have a working / approved GMF integration build we move these targets
back to the nightly builds and developers adopt as their new target.
I think we want to switch to the nightly build and developers running on a
target for a week before using them for the GMF integration builds. This way we
have a period of time to test and fix JUnit failures.
Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Manager - Software Developer,
IBM Rational Software: Aurora Core Common / Modeling Tools
Phone: 613-591-7037
"Richard Gronback"
<Richard.Gronback@xxxxxxxxxxx>
Sent by: gmf-dev-bounces@xxxxxxxxxxx
02/27/2006 06:58 PM
Please
respond to
"GMF Project developer discussions."
<gmf-dev@xxxxxxxxxxx>
|
|
To
|
<gmf-releng@xxxxxxxxxxx>
|
cc
|
gmf-dev@xxxxxxxxxxx
|
Subject
|
[gmf-dev] Build I20060227-1730 posted
|
|
http://download.eclipse.org/technology/gmf/downloads/drops/I-I20060227-200602271730/index.php
Note the updated dependencies (Platform 3.2M5a, EMF/GEF/EMFT M5) and some test
failures.
Are we OK to switch back to stable configurations for nightly builds, or should
we stick with weekly updates to the latest I-build in our dev environments?
Also, a new Linux build machine is being configured in Prague and will be managed by Max Feldman, who returns to GMF after a period away.
This should eliminate our connection timeout errors and path limit
problems.
Thanks,
Rich_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev