[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-dev] Integration build process
|
Tim,
- I agree with more stringent testing of the builds and giving more
responsibility to component owners in this process. We can use the
lists in
http://www.eclipse.org/webtools/wst/components.xml
and
http://www.eclipse.org/webtools/jst/components.xml for this task.
We should definitely follow these rules for M (Milestone) and (S) release builds. We have laid out a series of builds that will lead to an M/R build in . So we can make sure that the testing is also accounted for in this process.
However,
- I am not in favor of a very formal process for I-Builds. I-Builds are "marked" integration points for developers. It is important to set a rhythm and try to keep up with that. So I am in favor of staying away from formally declaring a build and integration build, no more than that it happens on thursdays. There can be couple of repeats during the day to fix problems. The point is that it is a labeled(versioned) build that provides a point of reference. This means that there will be problems in I-Builds and sometimes major ones, and that is ok. As david said, if some components have a long history of not beaing fixed. It will show.
At 03:35 PM 12/3/2004, you wrote:
Hi,
After asking around, no one has been able to tell me how an integration build is declared or when it happens. Therefore, I'd like to propose the following process:
*Component leads* are responsible for testing their component before an integration build occurs, to ensure that we catch last minute defects before the IB and go into it expecting to declare it immediately. Once the candidate integration build occurs, they must test again and let the subproject leads know whether the integration build is good for their component, or whether there are defects that they want to fix.
Note that the component leads do not actually need to do the testing themselves. :) They are just responsible for getting it done, and this may be using a combination of passing JUnit tests, manual testing by anyone familiar with the component, smoke testing, a formal FVT test, good reports on the newsgroup, etc.
*Subproject leads* are responsible for getting the reports from the component leads, following up if they haven't heard anything, and deciding together when to declare the IB. I'll assert that it is completely in their power to decide whether or not to declare the IB - for instance, they could declare an IB if they've heard good reports from 80% of the component leads but can't get ahold of the other leads and don't want to wait. And they can decide (with input from the component leads) whether a particular defect from one of the components is important enough to delay the IB and respin.
Once an IB is declared, or if it is delayed more than usual, the subproject leads are responsible for posting the information, either on the build page or to the mailing list.
Comments?
Thanks,
Tim deBoer
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503 (tieline 969)
deboer@xxxxxxxxxx
Naci Dai,
Managing Director
eteration a.s.
Inonu cad. Sumer sok. Zitas D1-15
Kozyatagi, Istanbul 81090
+90 (532) 573 7783 (cell)
+90 (216) 361 5434 (phone)
+90 (216) 361 2034 (fax)
http://www.eteration.com
mailto:nacidai@xxxxxxx
mailto:naci@xxxxxxxxxxxxx
