RE: [gmf-dev] Build I20060227-1730 posted

[Frederic Plante <fplante@xxxxxxxxxx>]

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