How to keep follow up fixes with the original ?

[David Holmes]

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
>