[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] Proposed build schedule for month of July
|
On Wed, Jun 27, 2012 at 7:18 PM, David M Williams
<david_williams@xxxxxxxxxx> wrote:
> .. The only potential problem is
> having two 4.3 integration builds a week, since some teams have a
> manual process for doing build input and it could create extra work
> for people. I would suggest making the Monday build an N-build
> rather than an I-build. ...
Well, I probably have a limited memory (joining near the
end of this cycle) .... I thought there were lots of I-builds through-out
the week, some being pseudo warm-ups for the main one on Tuesday.
Usually warm-up I Builds were done in the days leading into a milestone (and all Nightlies were stopped). Otherwise it was a single I Build on Tuesdays (and, IIRC, an NBuild every night at 8:00pm, even tuesday night). This was likely a lot easier when we had dedicated hardware at IBM, so dropping the N Build on Tuesday (and maybe evening Wednesday) seem reasonable.
Remember, the N Build doesn't give us any indication of whether the IBuild will succeed. The N Build is more of a poor-mans continuos
So, feel free to say what's desired. But, if I don't hear
other suggestions, complaints, advice, I'll schedule (Eastern times)
N builds, 8 AM, Friday, Sat, Sun, Mon
I would add thursday to this list. Others can decide on Wednesday.
cheers,
Ian
I build, 8 AM Tuesday
3.8 M build Thursday 8 AM
4.2 M build Thursday 10 AM
This leaves Wednesday as a sort of an "evaluation
day", see what you think of the I build, ask for respins if needed,
decide what to cherry pick for M builds, if anything.
And, again, I'm thinking of this as the July schedule
... we can always redo in August as we start meeting again, have firm delivery
dates in hand, etc.
Thanks,
From:
John Arthorne <John_Arthorne@xxxxxxxxxx>
To:
"General development
mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>,
Date:
06/27/2012 01:24 PM
Subject:
Re: [eclipse-dev]
Proposed build schedule for month of July
Sent by:
eclipse-dev-bounces@xxxxxxxxxxx
This looks reasonable to me David. The
only potential problem is having two 4.3 integration builds a week, since
some teams have a manual process for doing build input and it could create
extra work for people. I would suggest making the Monday build an N-build
rather than an I-build. Unless you were thinking that Monday I-build would
be a slot for extra test builds that we don't publish?
For dates, I think a reasonable guess is that Kepler M1 will be August
10th. For Juno SR1, I expect we will have RC1 on August 15th, and RC2 on
August 29th. David and I will work with the planning council to finalize
those dates and get a plan posted over the coming weeks.
John
Potential Discussion Topic for status/planning/architecture call:
I present this as a "straw man" proposal. I'd be fine with about
anything the team would find useful, but think we have a few constraints:
we have more builds than in the past, our unit test cycle takes (much)
longer than in the past. So, initially (month of July) I'd like to leave
plenty of "open time" to do special "test builds" to
more easily investigate unit test machines setup and issues.
proposed build schedule ... for month of July:
Assumptions:
Kepler M1: mid-August-ish
Juno SR1: fourth Friday of September (assuming we'll keep 4.2.1 and 3.8.1
"simultaneous") (so RC1 near end of August).
Goal, for July:
provide some regular builds for fixes/integration, etc., but also allow
time for deep investigation into unit tests setup/failures (which often
may require re-testing, without re-building, testing a limited set of suites,
and similar).
Proposed Schedule:
4.3 N builds: 8 PM Thursday, Friday, Sunday (none Saturday, assuming Hudson
is restarted overnight, so tests would not finish)
4.3 I builds: Monday, Tuesday 8 AM (and on demand)
3.8.1 Maintenance Thursday 10 AM (and on demand)
4.2.1 Maintenance Thursday 12 AM (noon) (and on demand)
Adjust at end of July as schedules better known, regular work rhythms resume,
and, we hope, unit test cycle reduced.
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com |
http://twitter.com/eclipsesource
