+1
I wonder if we should have some kind of guideline for when Europa
projects are encouraged to move to integration builds. Mylar is affected
by changes to SDK internals, so here is what we have been doing since 3.2M1:
* Monday of week of milestone release: we move HEAD to latest
I-build. Most Mylar committers work self-hosted, ensuring we can provide feedback
both on APIs and any implementation problems.
* Tue-Fri of milestone release: we release dev builds for I-builds
so that our more eager users to download and we get additional usage.
During key milestones (e.g. 3.2M5, 3.3M5) we have upped this
schedule by a week in order to try to give feedback as early as possible.
However, this time around moving to I-builds 2 weeks before the milestone
release did not work because they were too buggy to self-host on (views wouldn’t
open, PDE compilation problems), so we had to roll back HEAD and make patches.
So my question is: when would the Platform like Europa projects to move to
I-builds? Note that for Mylar this means that the I-build needs to work
well enough for us to self-host (it always has been by the Monday of the
milestone release week). This could be related to the “green build”
topic brought up recently.
Mik
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Kim
Moir
Sent: Thursday, February 22, 2007 6:38 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Fw: [platform-releng-dev]
request for M5 rebuild
+1
Thanks again to
Ed and Nick for testing our builds during M5 week.
If teams only
consume the builds they depend on every milestone, it is overly
optimistic to assume that there won't be any problems when they move up to the
milestone. Many changes go into a build over six weeks. Respinning
milestones is very expensive in terms of lost productivity and sleep
deprivation :-) I realize that it everyone is incredibly busy at this
time of year. Also, it is difficult to adjust to all the changes going
into the builds. However, if teams consume the builds they depend on an
ongoing basis, issues can be addressed earlier and will result in less stress
for all teams involved.
Kim
Ed
Merks/Toronto/IBM@IBMCA
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
02/22/2007
07:46 AM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
|
|
To
|
Cross
project issues <cross-project-issues-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
Re:
[cross-project-issues-dev] Fw: [platform-releng-dev] request
for M5 rebuild
|
|
Folks,
I wonder if these late breaking issues that require a respin of the
platform (or other dependencies) could be prevented? In my personal
effort to not be the one "blamed" for this year's M5a---yes,
that's right,
the messenger is perhaps not blamed but is certainly so closely
associated
with the problem that it will appear that way---I had installed a
pre-M5
integration build (I20070207) to confirm that from an EMF point of view, M5
would be in good shape. Even though all looked great, bugzilla
https://bugs.eclipse.org/bugs/show_bug.cgi?id=173741managed to creep in as
part of the fix for
https://bugs.eclipse.org/bugs/show_bug.cgi?id=172451after I picked up this
integration build (i.e., two days before the milestone). This problem
results in the IDE turning to the Error log view whenever we create an new
EMF project, i.e., pretty much every EMF demo leads to this.
Fortunately
there's a preference setting that disables the build.properties check and
prevents the logged exception, so there was no need to ask for a respin of
M5a, but it was a very close call, and would have resulted in undesirable
attention for the third year in a row. (So woo hoo, M5a is not my
fault
this year!)
Jokes aside, there is a good reason that the messenger is typically partly
to blame because I get the impression that most groups simply don't try the
integration builds at all, and if act, don't even do "test"
builds to
confirm that the pre-milestone integration builds are in minimally good
shape from their project's point of view, i.e., that your project compiles
with it and that the JUnit tests pass. Consider how many groups had
to
scramble to deal with the startup.jar issue at the last minute even though
the issue has been waiting to bite them for weeks? I'm sure many
teams are
just as strapped for time and resource as the EMF team making it a
challenge to ask developers to pick up an integration build and manually
test with it, but it should be clear that it's in each of our own project's
best interests to ensure that the M5 build, which is so important for
demonstration purposes at EclipseCon, ends up being a solid one for which
our project works well. So while we are all clearly responsible for
our
own project being in good shape, we also bear some responsibility for
ensuring that the closure of all our dependencies is also in good shape.
If we don't intend to ask for a respin when we find problems in our
dependencies, it's fine to sit back and wait for a milestone, but when we
expect that problems we find will result in us asking for respins, I would
suggest that we should do just a little bit more, especially for the
EclipseCon milestone...
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 969)
Sonia
Dimitrov/Ottawa/I
BM@IBMCA
To
Sent by:
Cross project issues
cross-project-iss
<cross-project-issues-dev@eclipse.o
ues-dev-bounces@e
rg>
clipse.org
cc
Subject
02/21/2007 07:46
Re: [cross-project-issues-dev] Fw:
PM
[platform-releng-dev]
request for
M5 rebuild
Please respond to
Cross project
issues
<cross-project-is
sues-dev@eclipse.
org>
Build I20070221-1750 failed, and a fix has been released to address
this.
A rebuild will be delayed however while the Platform UI team considers a
separate request to fix:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=174355
Sonia
Tod Creasey/Ottawa/IBM@IBMCA
Sent by:
cross-project-issues-dev-bounc
To
es@xxxxxxxxxxx
Cross project issues
<cross-project-issues-dev@eclipse
.org>
02/21/2007 06:18 PM
cc
Subject
Please respond to
[cross-project-issues-dev] Fw:
Cross project issues
[platform-releng-dev] request for
<cross-project-issues-dev@ecl M5
rebuild
ipse.org>
Platform UA has requested a rebuild of 3.3 M5 to deal with Bug 17444:
FormColors broken in 3.3 M5 (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=174441). M5 has a UI forms
colour constant (IFormColors.TB_GBG) for which it returns a null Color.
This causes the project explorer to become unresponsive when using tabbed
properties. It can also cause problems in other code that uses this
color.
For your Europa M5 verification you should install on top of build
I20070221-1750 which should be promoted to M5a once the fix for Bug 174441
is verified.
Apologies for this late change.
Tod and Boris
Platform UI Team
----- Forwarded by Tod Creasey/Ottawa/IBM on 02/21/2007 05:50 PM -----
Curtis D'Entremont/Toronto/IBM@IBMCA
Sent by:
platform-releng-dev-bounces@xxxxxxxxxxx
To
platform-releng-d
02/21/2007 05:39 PM
ev@xxxxxxxxxxx
cc
Please respond to
Subject
"Eclipse platform release engineering list."
[platform-releng-
<platform-releng-dev@xxxxxxxxxxx>
dev] request for
M5 rebuild
The UA team is requesting a rebuild of M5 to address a problem in Forms
that is seriously impacting other eclipse projects. The bug is:
Bug 174441 FormColors broken in 3.3 M5
https://bugs.eclipse.org/bugs/show_bug.cgi?id=174441
The map files have been updated for the branch and we are ready for the
rebuild. We sincerely apologize to the victims and their families for this
tragedy.
Curt_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev