[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [wtp-releng] What's happened to our M3 candidate!!
|
See comments inline. In short, there is not reason to
panic.
First, the builds broke
completely, since someone removed all source from
org.eclipse.jst.jee/appclientcreation
but did not remove appclientcreation
from the build.properties.
(a missing "source" entry is considered a fatel
error).
So, I fixed and released that
change to build.properties ... assuming it really was supposed to have been
removed???
But, maybe it was not
supposed to have been removed, and that's the cause of one or both of the next
two problems???
[kosta] Thanks for fixing up the build.properties files. The change was
intentional (part of merging of j2ee/jee - related facets code, the separation
of which was causing a lot of issues).
Second, there is a compile error in org.eclipse.jst.jsf.ui
From the history, there's been no change
in jst.ui that would account for it. That is a HUGE error to introduce after the M3 candidate has been
produced. What happened? Are our adopter
clients going to have the same problem? Have we forgotten the priniciple of not breaking adopters? (including our
own adoption!!) Have we forgotten the
principle of deprecating function, instead of just removing it?
[kosta] Absolutely no reason to panic. The change was
unintentional. This is the type of problem we have automated builds to
catch. I will clear this up
shortly.
Third, there is now 337 JUnit failures!!! After the M3 candidate was
produced?!
We should have been fixing
the two JUnit failures, not adding more.
[kosta] While the declared i-build seemed ok on the
surface, it really wasn't and we are making progress. While 337 seems like
a large number, they are all likely a result of one or two problems. I am
investigating.
I suspect there's perfectly reasonable explainations for all this, but
thought I'd send this note
to make clear
that those explainations should be documented here on wtp-releng for all of
us to understand.
Do we need to revert something in the interst of
stability?
[kosta] Not if we want to make progress. It has been plenty
evident that trying to sandbox large changes does not subject them to
sufficient testing to flush all the problems out and you just have to work
through the issues once the change is released. Reverting doesn't accomplish
much since it makes it impossible to debug/fix the
problems.
I should add that I appreciate agressive programming ... as long as it's
done as a coordinated team,
and everyone
can react immediately (e.g. over the weekend), and as long as the impact to our
many adopters is clear and well
documnted.
Thank you.
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
