[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [gmf-dev] Build I20060227-1730 posted
|
Hi Rich,
That sounds reasonable.
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 05:26 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 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_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
