| Re: [wtp-releng] Fw: [wtp-R3.0-I] wtp-R3.0-I build.57 Build Successful ... but |
Leaving aside the recent issue for which I apologize, and which I think resulted from a combination of miscommunication (Oracle's web e-mail system has been very flaky over the past 72 hours) and tactical problems with our JUnit framework with which we are struggling to address...
It seems to me, that the root problem here is that the build system cannot be easily reproduced outside the build servers (at least not at Oracle, by me). The result is that while we make our best effort to ensure that everything builds and tests correctly before committing and releasing, we never really know what's going to happen until we formally release.
I suggest one short term and one long term remedy:
Short term, re-enable regular HEAD builds. HEAD builds should run at least once per day. Every commericial development shop I've worked in over the past 10 years uses this practice. In this way, we will know as soon as possible if a change we've made is not going to fly. Many of the recent problems coming from JSF have resulted from configuration issues that would have been picked up early by such a mechanism and could have been addressed before an I-build was halted.
Long term, let's endeavour to make it simple and easy for any one who wants to, to download and reproduce the build system. I tried about 18 months ago to create a local instance at Oracle and threw my hands up after about a week of trying. If there have been improvements since, that will make it easy, I'm game to give it another kick. If not, let's work on it, starting with the biggest obstacle for us: we don't all live behind transparent web proxies (this is a problem with some WTP frameworks too by the way). To even get the build to download Eclipse dependencies I had to hack the ant scripts extensively to support CVS proxying through the Oracle firewall.
--Cam
--- Original Message ---
Raghu, this build was kicked off by you late Saturday, by releasing some new code for the new design test plugin ... after I had removed that suite from the master list. In other words, your release was not to fix a problem we were waiting for (to declare) and it had no effect (since that test isn't ran any longer) except to cause another build to be done and all the other tests to be re-ran ... .all of which caused me extra work. Since I had already said which was our final build, (pending smoke tests), it is confusing to then have another one listed there ... someone has to figure our why (which I did this time) ... since, maybe someone did fix a blocking bug (which is the normal case, when this happens) ... and if it is not needed to fix a blocking bug, then it should be removed to avoid confusion (which I did this time, too). In the past, I haven't minded doing some of this routine "build herding" because it didn't take much time, and was a good way to stay in touch with all the teams work. But, lately it has been nearly all day, every day ... which is unacceptable and a waste of my time. So, I hope there wasn't a simple miscommunication, but I fear the procedure still is not clear after all this time: No one should release anything, while we are waiting for a build to be declared, unless it is to fix a blocking problem. (While I don't recommend it, you can commit code to head, if you'd like, just don't release it). If this build and junit situation doesn't improve soon, I think it might be a good practice to rotate the weekly responsibility between the project leads ... perhaps that will raise appreciation for how important it is to get things correct. before you put in a build (and, how hard it is to get the rest of the project leads to comply or respond in a timely manner). And, for those of you who are always on time, and seldom cause build problems, your efforts are appreciated and do not go unnoticed. Constructive suggestions for how to improve our process are welcome. ----- Forwarded by David M Williams/Raleigh/IBM on 01/27/2008 02:33 AM -----
View results here -> http://build.eclipse.org:7777/dashboard/build/detail/wtp-R3.0-I?log=log20080127020914Lbuild.57 |