Hi Lana,
On 17/04/2015 2:28 PM, Lana Steuck wrote:
Hi David,
> We need something in place to ensure this doesn't happen!
We push to Master after team forests successfully go through the
following PIT steps:
- full build (hotspot ... install) for all 7 platforms
- fastdebug builds for all 7 platforms
- boot_cycle builds
- extended set of JPRT tests (the failures are getting OK-ed by dev)
- SQE teams are informed and list of fixes are submitted to SQE db
- manual testing of client-libs on main platforms.
The PIT process can be beefed up to cover more scenarios, however
there's always a cost that comes with it. At the end, it's a balance of
cost-benefits and potential risks.
The problem, in both cases (hence the 'again') affected builds where
configure was not run from directly inside the source tree. I thought
that between developers builds, JPRT builds, RE builds and PIT builds,
we had the two basic cases covered, but somehow these slipped through.
But that's not my main concern - mistakes happen.
> We need something in place to ensure this doesn't happen!
Do you see a simple way to prevent it? Usually people familiar with the
fix/issue contact me to let me know if they need an extra PIT restart or
if they need the PIT to be delayed - I can always move deadline for a
few hours, even a day if needed - just let me know.
I don't see a simple way. :) Somehow we need to associate two
changesets/bugs such that they are guaranteed/required to be pushed
around together. I don't think we have any automated capabilities for
that - though I can imagine some kind of JBS relationship that jcheck
would look for. Maybe the manual process of contacting you needs to be
formalized a bit (not everyone knows what a wonderful job you do ;-) )
such that an email can be sent to a well-known address to report the
problem. But of course that doesn't help if you don't realize there is a
need to do this - which comes down to education I guess: hence this
email. :)
Aside: anti-deltas wouldn't help in this case either, but the ability to
really rollback changesets would. :)
I should also note that the scope of this particular problem is smaller
than I had thought, because I thought JPRT builds would be affected -
but they aren't. So its only some of us poor end developers who may get
bitten.
Thanks,
David
Thank you,
Lana
On 04/16/2015 08:07 PM, David Holmes wrote:
It has happened again that a broken fix, for which there was a quick
follow up fix, has been pushed to the master without the follow up fix
going with it. So now everyone will potentially be impacted by the bad
fix as it propagates back down to all the forests :(
Bad fix:
https://bugs.openjdk.java.net/browse/JDK-8073634
Follow up:
https://bugs.openjdk.java.net/browse/JDK-8077563
We need something in place to ensure this doesn't happen!
David
