[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cosmos-dev] Builds during the QA phase
|
For easy reference for the Community
call, I've summarized this thread here: http://wiki.eclipse.org/COSMOS_PROPOSAL_ITERATION
Don, in that document I've included
a link to the TPTP definition of what a "blocker" defect is.
For your quick reference, this is the link: http://www.eclipse.org/tptp/home/documents/process/development/bugzilla.html
Feel free to mark up that wiki page
before the Community call.
Ruth Lee
IBM Toronto Lab
ruthdaly@xxxxxxxxxx
T/L 313-4453
"Ebright, Don"
<Don.Ebright@xxxxxxxxxxxxx>
Sent by: cosmos-dev-bounces@xxxxxxxxxxx
02/15/2008 10:37 AM
Please respond to
Cosmos Dev <cosmos-dev@xxxxxxxxxxx> |
|
To
| "Cosmos Dev" <cosmos-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [cosmos-dev] Builds during the QA
phase |
|
Jimmy,
In my opinion, after development
is closed for an iteration, we should only fix defects that we have designated
as blockers. We need processes to agree on whether a particular defect
is a blocker and the discipline to keep other changes from being checked
in.
The last build is the first one
that has no blocking defects :)
Don
From: cosmos-dev-bounces@xxxxxxxxxxx
[mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Mohsin, Jimmy
Sent: Friday, February 15, 2008 9:02 AM
To: Cosmos Dev
Subject: [cosmos-dev] Builds during the QA phase
Ruth,
To add to Don’s comment in regards
to rigor, we have a fairly good process for the pre-QA handoff. Is
it safe to assume that this process (or some form thereof) would be needed
for the post-QA handoff situation as well?
Specifically, given that QA runs
for 2 weeks (typically) in each iteration, here are some questions that
came up in i8;
·
What sort of Defects warrant
a new build during the QA phase?
·
If there is a build happening
to fix a high priority Defect, can lower priority defect fixes be sneaked
in as well?
·
What role should a Lead have
in a QA phase build?
·
What metric do we use to define
the LAST build during the QA phase to mark the iteration closed? FYI,
last time around, there was a lot of confusion in regards to this point
and there was a weekend emergency.
Thanks,
Jimmy Mohsin
Cell +1-609-635-1703
From: cosmos-dev-bounces@xxxxxxxxxxx
[mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Ebright, Don
Sent: Friday, February 15, 2008 7:52 AM
To: Cosmos Dev
Subject: RE: [cosmos-dev] REVIEW REQUESTED TODAY: Code CutoffforWeekly
Integration Builds
Ruth,
Thank you for starting this discussion.
We are reaching the stage where
it will be crucial for us to follow a well understood, rigorous, and transparent
shutdown process. This sounds like a very well thought out proposal, and
I think that it would be worth discussion on next week's community call.
Don
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
From: cosmos-dev-bounces@xxxxxxxxxxx
[mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Ruth Lee
Sent: Thursday, February 14, 2008 4:21 PM
To: Cosmos Dev
Subject: Re: [cosmos-dev] REVIEW REQUESTED TODAY: Code Cutoff forWeekly
Integration Builds
Hi Tania,
On a related topic, can we discuss the details for the iteration build
in the next Community call, please? We discussed some of what's needed
for the iteration build in the last Summit call but some details were not
fleshed out. I'd like to summarize my expectation of what RE is being asked
to do and close on the details so that everyone is clear on what's happening.
I've filled in the details based a little bit on what happened in TPTP
and I expect that there will be some debate and we'll need to finalize
this in the next Community call.
Declaring an integration driver
* During the last week of development in the
iteration, all code check-ins stop once the candidate weekly integration
driver is built.
* RE announces the candidate weekly integration
driver but CVS is not yet open for new code. COSMOS is in shut-down
mode. The JUnits will be run on the candidate weekly driver, the results
posted to cosmos-dev, and the results reviewed in the Architecture call
as usual.
* During shut-down mode, if a developer wants
to check in any changes for the candidate iteration build, that developer
must request permission from the Leads (Project, Architecture) before those
changes are checked in.
* The developer sends the request for permission
to the cosmos-mgmt mailing list. This request identifies the changes to
be checked in, why they can't be deferred to a future iteration, and the
risk of the change. (Where "risk" means "what could be broken
if we allow this change?".)
* A Lead allows or defers the changes and cc
RE so that RE can track the list of bugzillas allowed in. RE maintains
a wiki site with a cumulative list of the bugzilla numbers and details
provided by the developers.
* On Friday morning at 9:00 AM, RE sends that
list of bugzillas and files changed to cosmos-dev and anyone affected by
any of the changes checked in during shut-down mode runs the JUnits that
test just the affected code. (Don't know if it's possible to separate the
JUnits like that, but that's the ideal to reduce the amount of time needed
for testing.) Any problems found are fixed ASAP.
* On Monday at 9:00 AM, someone from RE will
send a post to cosmos-dev identifying the official integration driver to
be used for the testing and stating that CVS is now open.
The reason we moved the code cutoff is so that we would have two days to
identify and fix major problems before turning the build over to QA without
working through the weekend. Requiring approval for check-ins would
give us time to make sure the build is stable and give a small amount of
flexibility to check in last-minute code.
Thanks,
Ruth.
Ruth Lee
IBM Toronto Lab
ruthdaly@xxxxxxxxxx
T/L 313-4453
Tania N Makins <tmakins@xxxxxxxxxx>
Sent by: cosmos-dev-bounces@xxxxxxxxxxx
02/14/2008 01:51 PM
Please respond to
Cosmos Dev <cosmos-dev@xxxxxxxxxxx> |
|
To
| "Cosmos Dev" <cosmos-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| [cosmos-dev] REVIEW REQUESTED TODAY: Code
Cutoff for Weekly Integration Builds |
|
Team,
Please review the process changes related to code cutoff for the weekly
integration builds below and respond with comments or a +1 if you are in
agreement by EOD today.
Weekly Integration Builds
- Weekly integration builds will be run every
Tuesday at 12:00
p.m. ET
- Code cutoff for integration builds is as
follows:
- All patches should be in bugzilla by Monday
at 12:00 p.m. ET
- All code should be checked into CVS by 11:45
a.m. ET on Tuesday
- CVS will be locked until the
build has completed successfully (typically for 1 hour). No code
should be checked in from 11:45 a.m. on Tuesday until notification of build
completion has been sent out.
- Each subproject team should run JUnits on
the candidate build and post results by 10:00
a.m. on Wednesday to be reviewed
during the architecture call. JUnits should be run individually so that
results can be reported accurately. (Note: The Data Visualization team
will perform a smoke test on the UI since the tests are manual)
- RE team will post notification to cosmos-dev
when the integration build is ready - target availability is 4:00 p.m.
on Wednesdays
Tania N. Makins, PMP®
Project Manager, AC Open Source Components
IBM Software Group - RTP, NC
Office: (919) 254-8430 T/L: 444-8430
tmakins@xxxxxxxxxx_______________________________________________
cosmos-dev mailing list
cosmos-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cosmos-dev
_______________________________________________
cosmos-dev mailing list
cosmos-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cosmos-dev