[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[wtp-releng] More on build and tests issues ...
|
Thanks Cam, these are good constructive
comments.
1. On the matter of HEAD builds: These
are possible now. We do them on request only, since they have limited value
unless someone has made "big changes". (And, since I think all
the project's should be able to do this locally ... which is your number
2 point, and also since you should be able to do in a pure development
environment -- for example, when I run your tests in org.eclipse.jst.jsf.designtime.tests
in my development environment, I get 1 error and 2 failures. You don't?
I've opened bug
216704. if it helps provide more
data.)
So, how do you make a request for a
HEAD build? Well, you could post here to wtp-releng. Or, better you could
kick one off yourself. Just go to
http://build.eclipse.org:7777/dashboard/dashboard?s=1
or
http://build.eclipse.org:7777/dashboard/dashboard?s=1
and press "build" on the project
called wtp-R3.0-N (n is for the archaic "nightly" build).
If you did one now, for example, you'd
see there are 23 compile failures in HEAD ... the same thing you'd see
if you loaded up head in a special workspace on your machine.
(I know, people always says that takes
a long time ... but, it's no longer than to do a local build ... the trick
is to really have a special workspace, just for this purpose, not necessarily
the one you use day-to-day).
Of course, Wednesday afternoon, while
we are trying to produce a weekly Integration build is not the time to
request a HEAD build ... as it could get in the queue in front of an I-build
teams were waiting for .... but today would be good :) Well, it would
be good, except I was forced to remove your org.eclipse.jst.jsf.designtime.tests
from the master list, so those still won't run.
So, apologies ... it appears I have
not communicating this "on request" feature well enough.
2. On the matter of doing local builds,
I suspect it's easier than you think, and its just not documented well.
So, will work on that.
But, it's a LOT easier than it was 18
months ago! Well, I think.
But, in the mean time, ask if questions
come
up, or open bugs ... I've always
found that's the best way to produce a "FAQ" on a topic.
And, "ask fast" before frustration
sits in. Perhaps we should schedule a "live demo" for some status
meeting?
Hmm, I wonder if our web-conference
software works on Linux :)
Also, don't forget you can open bugs
(and supply patches :) on things you'd like to see changed. It's definitely
a "help wanted" item!
You might query for bugs from tran.le
... he's apparently had some success building on oracle's infrastructure
(though I'm sure not perfect,
since it does pretty much require linux-like systems to
build (window's has trouble with some path lengths, and other tasks).
Hope this helps, ... thanks for your helpful comments.
From:
| CAMERON.BATEMAN@xxxxxxxxxx
|
To:
| "wtp-releng@xxxxxxxxxxx" <wtp-releng@xxxxxxxxxxx>
|
Date:
| 01/27/2008 03:40 AM
|
Subject:
| 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
-----
From:
| David M Williams/Raleigh/IBM@IBMUS
|
To:
| David M Williams/Raleigh/IBM@IBMUS,
raghunathan.srinivasan@xxxxxxxxxx
|
Date:
| 01/27/2008 12:08 AM
|
Subject:
| [wtp-R3.0-I] wtp-R3.0-I build.57 Build
Successful |
View results here -> http://build.eclipse.org:7777/dashboard/build/detail/wtp-R3.0-I?log=log20080127020914Lbuild.57 |
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng