Repository? -- How many lines of development?

[Rory O'Donnell]

Hi Martin,

We investigated the large number of failures in b146, the RMI failures 
were due to missing @build TestLibrary.

https://bugs.openjdk.java.net/browse/JDK-8170660

This issue was fixed in b148.

Rgds,Rory


On 29/11/2016 08:51, Rory O'Donnell wrote:
>
> Hi Martin,
>
>
> On 28/11/2016 20:15, Martin Buchholz wrote:
>>
>>
>> On Fri, Nov 18, 2016 at 8:33 AM, joe darcy <joe.darcy at oracle.com 
>> <mailto:joe.darcy at oracle.com>> wrote:
>>
>>     * A master forest, serving the roles master and dev play today in 9.
>>
>>     With a few exceptions, in JDK 9 master was just time-delayed copy
>>     of dev so we can implement recording the  information about which
>>     set of sources correspond to a promoted build without using a
>>     whole other forest.
>>
>>     Rather than using a separate line of development for client-libs
>>     work as in 9, I think this should be done in the same line of
>>     development as all other libs work in 10.
>>
>>
>> For many years, I've been advocating having a guaranteed 
>> always-working, never regressing master and also always a place for 
>> developers to submit-and-forget their (possibly slightly buggy) 
>> changes.  All regressions that could be caught by a test are 100% 
>> guaranteed to be caught by a competent trusted release engineer who 
>> is the only one ever moving changes into the master forest.  Based on 
>> this idea, it seems essential to have something like a jdk10-dev 
>> forest (it could also be implemented using mercurial branches, but 
>> that would be a break with many decades of tradition).
>>
>> I notice today the message
>> http://mail.openjdk.java.net/pipermail/quality-discuss/2016-November/000596.html
>> where regressions have crept into a jdk9 build, which is 
>> disappointing.  The whole point of regression testing is to ensure 
>> that regressions don't happen!  And I recall having that job myself 
>> back in 2005!
> We are investigating these failures.
>
> The reason for posting results, warts and all, is to allow others to 
> have results to compare with.
> The number of failures , in this instance, is unusually high.
>
> Rgds,Rory
>
>
> -- 
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161223/98be93de/attachment.html>