From eric.caspole at oracle.com  Fri May  3 14:52:34 2019
From: eric.caspole at oracle.com (Eric Caspole)
Date: Fri, 3 May 2019 10:52:34 -0400
Subject: Result: New Code Tools Committer: Sergey Kuksenko
In-Reply-To: <032a4727-5a6c-320e-256e-d4d883314b39@oracle.com>
References: <032a4727-5a6c-320e-256e-d4d883314b39@oracle.com>
Message-ID: <75361ea2-0e46-3737-2b74-a675afe3d6e0@oracle.com>

Voting for Sergey Kuksenko [1] is now closed.

Yes: 3
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Eric Caspole

[1] 
https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-April/000528.html


On 4/17/19 12:12, eric.caspole at oracle.com wrote:
> I hereby nominate Sergey Kuksenko to Code Tools Committer.
> 
> Sergey has contributed 10 changesets to JMH and he was one of the 
> original developers of JMH before it was contributed into OpenJDK.
> 
> He is also a JDK and Valhalla Committer.
> 
> Votes are due by 1pm Eastern, May 1, 2019. Only current Code Tools 
> Committers [1] are eligible to vote on this nomination.? Votes must be 
> cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> -- Eric Caspole
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote

From patrick at os.amperecomputing.com  Mon May  6 05:45:26 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Mon, 6 May 2019 05:45:26 +0000
Subject: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load
 GetSystemProperty.class when debugging
In-Reply-To: <BYAPR01MB504660A16E16C0CEE16E81C68F3D0@BYAPR01MB5046.prod.exchangelabs.com>
References: <BYAPR01MB50460C74CC4A48C4066FEC9D8F230@BYAPR01MB5046.prod.exchangelabs.com>
 <4aa20099-0321-a90a-c54c-cd634c62b0cf@oracle.com>
 <BYAPR01MB50466F9B95CAEE992A60B20F8F3C0@BYAPR01MB5046.prod.exchangelabs.com>
 <013fd618-b5ad-bcf3-db22-77937684d512@oracle.com>
 <BYAPR01MB504660A16E16C0CEE16E81C68F3D0@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <BYAPR01MB50461F458557DBBE23DE24848F300@BYAPR01MB5046.prod.exchangelabs.com>

Hi Reviewers,

Could you please help review it? Thanks.
JBS: https://bugs.openjdk.java.net/browse/CODETOOLS-7902453 
Webrev: http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.03 

Regards
Patrick

-----Original Message-----
From: code-tools-dev <code-tools-dev-bounces at openjdk.java.net> On Behalf Of Patrick Zhang OS
Sent: Thursday, April 25, 2019 10:29 AM
To: Jonathan Gibbons <jonathan.gibbons at oracle.com>; code-tools-dev at openjdk.java.net
Subject: RE: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load GetSystemProperty.class when debugging

> That would be inappropriate, and against long-standing jtreg policy of being susceptible to the user's environment.

Fine, I was thinking the change at least would not make things worse, while it sounds CLASSPATH got intentionally cleared here, and cleanly written with the path of jtreg.jar and javatest.jar.
Dropped that part, please review this update: http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.03, thanks.

Regards
Patrick

-----Original Message-----
From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
Sent: Thursday, April 25, 2019 1:54 AM
To: Patrick Zhang OS <patrick at os.amperecomputing.com>; code-tools-dev at openjdk.java.net
Subject: Re: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load GetSystemProperty.class when debugging

> I would like to keep the fix for CLASSPATH, which should not be overwritten regardless. Maybe there were predefined values inside from users.

That would be inappropriate, and against long-standing jtreg policy of being susceptible to the user's environment.

-- Jon


On 04/24/2019 12:46 AM, Patrick Zhang OS wrote:
> Hi Jon,
> Thanks for your review.
> Please see my updates: http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.02. Instead of modifying sysPropClassPath directly, I changed JarFinder.getPath() a little bit: if the URI is not JAR, try the root path of class files.
> I would like to keep the fix for CLASSPATH, which should not be overwritten regardless. Maybe there were predefined values inside from users.
>
> Regards
> Patrick
>
> -----Original Message-----
> From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
> Sent: Tuesday, April 23, 2019 10:50 PM
> To: Patrick Zhang OS <patrick at os.amperecomputing.com>; 
> code-tools-dev at openjdk.java.net
> Subject: Re: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to 
> load GetSystemProperty.class when debugging
>
> Since sysPropClassPath is supposed to contain the path, and does not, it would be better to fix sysPropClassPath to contain the correct value.
>
> -- Jon
>
> On 4/23/19 2:58 AM, Patrick Zhang OS wrote:
>> Hi,
>>
>> I ran into an issue that jtreg reported that it cannot determine version for JDK when debugging, while the root cause is the root directory of class files could not be located correctly. There are a couple of methods to solve the problem (see details in JBS), the proposed one is to make com/sun/javatest/regtest/config/JDK.java not overwrite the CLASSPATH env var completely, update it with added paths instead.
>> Please review, thanks.
>>
>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902453
>> Webrev:
>> http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.01/
>>
>> Regards
>> Patrick
>>


From jonathan.gibbons at oracle.com  Fri May 10 17:29:45 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 10 May 2019 10:29:45 -0700
Subject: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load
 GetSystemProperty.class when debugging
In-Reply-To: <BYAPR01MB50461F458557DBBE23DE24848F300@BYAPR01MB5046.prod.exchangelabs.com>
References: <BYAPR01MB50460C74CC4A48C4066FEC9D8F230@BYAPR01MB5046.prod.exchangelabs.com>
 <4aa20099-0321-a90a-c54c-cd634c62b0cf@oracle.com>
 <BYAPR01MB50466F9B95CAEE992A60B20F8F3C0@BYAPR01MB5046.prod.exchangelabs.com>
 <013fd618-b5ad-bcf3-db22-77937684d512@oracle.com>
 <BYAPR01MB504660A16E16C0CEE16E81C68F3D0@BYAPR01MB5046.prod.exchangelabs.com>
 <BYAPR01MB50461F458557DBBE23DE24848F300@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <6507060c-031c-5140-c2c7-7330c3250d87@oracle.com>

Patrick,

The basic patch looks OK.

I'm seeing some probably-unrelated issues running the jtreg tests, and 
so I'll push your patch when those issues are sorted out.

One the subject of tests, it is strongly desired that all non-trivial 
patches should have a corresponding test. This is not just good 
practice, it should also be seen as a defense mechanism against the 
patch failing in the future. In general, it is not enough to just run 
jtreg once or twise with a patch, and eyeball the results in some 
private configuration. In this case, a reasonable test would be to run 
jtreg with the classes (instead of the jar file) on the classpath.

-- Jon


On 05/05/2019 10:45 PM, Patrick Zhang OS wrote:
> Hi Reviewers,
>
> Could you please help review it? Thanks.
> JBS: https://bugs.openjdk.java.net/browse/CODETOOLS-7902453
> Webrev: http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.03
>
> Regards
> Patrick
>
> -----Original Message-----
> From: code-tools-dev <code-tools-dev-bounces at openjdk.java.net> On Behalf Of Patrick Zhang OS
> Sent: Thursday, April 25, 2019 10:29 AM
> To: Jonathan Gibbons <jonathan.gibbons at oracle.com>; code-tools-dev at openjdk.java.net
> Subject: RE: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load GetSystemProperty.class when debugging
>
>> That would be inappropriate, and against long-standing jtreg policy of being susceptible to the user's environment.
> Fine, I was thinking the change at least would not make things worse, while it sounds CLASSPATH got intentionally cleared here, and cleanly written with the path of jtreg.jar and javatest.jar.
> Dropped that part, please review this update: http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.03, thanks.
>
> Regards
> Patrick
>
> -----Original Message-----
> From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
> Sent: Thursday, April 25, 2019 1:54 AM
> To: Patrick Zhang OS <patrick at os.amperecomputing.com>; code-tools-dev at openjdk.java.net
> Subject: Re: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load GetSystemProperty.class when debugging
>
>> I would like to keep the fix for CLASSPATH, which should not be overwritten regardless. Maybe there were predefined values inside from users.
> That would be inappropriate, and against long-standing jtreg policy of being susceptible to the user's environment.
>
> -- Jon
>
>
> On 04/24/2019 12:46 AM, Patrick Zhang OS wrote:
>> Hi Jon,
>> Thanks for your review.
>> Please see my updates: http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.02. Instead of modifying sysPropClassPath directly, I changed JarFinder.getPath() a little bit: if the URI is not JAR, try the root path of class files.
>> I would like to keep the fix for CLASSPATH, which should not be overwritten regardless. Maybe there were predefined values inside from users.
>>
>> Regards
>> Patrick
>>
>> -----Original Message-----
>> From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
>> Sent: Tuesday, April 23, 2019 10:50 PM
>> To: Patrick Zhang OS <patrick at os.amperecomputing.com>;
>> code-tools-dev at openjdk.java.net
>> Subject: Re: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to
>> load GetSystemProperty.class when debugging
>>
>> Since sysPropClassPath is supposed to contain the path, and does not, it would be better to fix sysPropClassPath to contain the correct value.
>>
>> -- Jon
>>
>> On 4/23/19 2:58 AM, Patrick Zhang OS wrote:
>>> Hi,
>>>
>>> I ran into an issue that jtreg reported that it cannot determine version for JDK when debugging, while the root cause is the root directory of class files could not be located correctly. There are a couple of methods to solve the problem (see details in JBS), the proposed one is to make com/sun/javatest/regtest/config/JDK.java not overwrite the CLASSPATH env var completely, update it with added paths instead.
>>> Please review, thanks.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902453
>>> Webrev:
>>> http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.01/
>>>
>>> Regards
>>> Patrick
>>>


From gnu.andrew at redhat.com  Mon May 13 17:33:00 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 13 May 2019 18:33:00 +0100
Subject: [RFR] 7902421: jcheck fails with mercurial 4.8
In-Reply-To: <9d5abe47-5408-6ebe-8e97-765396889adc@redhat.com>
References: <9d5abe47-5408-6ebe-8e97-765396889adc@redhat.com>
Message-ID: <8d02e6f4-7d13-144a-e954-fb96f103a45a@redhat.com>



On 22/03/2019 00:59, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902421
> Webrev: https://cr.openjdk.java.net/~andrew/codetools/7902421/webrev.01/
> 
> Mercurial pull requests started failing after upgrading to 4.8.1:
> 
> File "/home/andrew/projects/openjdk/jcheck/jcheck.py", line 745, in hook
>     ch.check(repo.changelog.node(rev))
>   File "/home/andrew/projects/openjdk/jcheck/jcheck.py", line 688, in check
>     ctx = context.changectx(self.repo, node)
> 
> This seems to be because context.changectx now takes an additional argument:
> 
> ArgSpec(args=['self', 'repo', 'rev', 'node'], varargs=None,
> keywords=None, defaults=None)
> 
> so I made changes to pass through the rev argument. This fixes the
> problem and I can pull in changes again.
> 
> I couldn't see any clear mention in the Mercurial code of why this rev
> argument is now required or any explanation of the change on their
> website. Not being overly familiar with either the Mercurial or jcheck
> code, this may be the wrong approach, but it seems to be working so far
> for me.
> 

Ping?
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From erik.joelsson at oracle.com  Mon May 13 17:39:56 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 13 May 2019 10:39:56 -0700
Subject: [RFR] 7902421: jcheck fails with mercurial 4.8
In-Reply-To: <8d02e6f4-7d13-144a-e954-fb96f103a45a@redhat.com>
References: <9d5abe47-5408-6ebe-8e97-765396889adc@redhat.com>
 <8d02e6f4-7d13-144a-e954-fb96f103a45a@redhat.com>
Message-ID: <cb7d2bb4-6a3d-7008-6193-2976c32294b5@oracle.com>

Looks ok to me.

/Erik

On 2019-05-13 10:33, Andrew John Hughes wrote:
>
> On 22/03/2019 00:59, Andrew John Hughes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902421
>> Webrev: https://cr.openjdk.java.net/~andrew/codetools/7902421/webrev.01/
>>
>> Mercurial pull requests started failing after upgrading to 4.8.1:
>>
>> File "/home/andrew/projects/openjdk/jcheck/jcheck.py", line 745, in hook
>>      ch.check(repo.changelog.node(rev))
>>    File "/home/andrew/projects/openjdk/jcheck/jcheck.py", line 688, in check
>>      ctx = context.changectx(self.repo, node)
>>
>> This seems to be because context.changectx now takes an additional argument:
>>
>> ArgSpec(args=['self', 'repo', 'rev', 'node'], varargs=None,
>> keywords=None, defaults=None)
>>
>> so I made changes to pass through the rev argument. This fixes the
>> problem and I can pull in changes again.
>>
>> I couldn't see any clear mention in the Mercurial code of why this rev
>> argument is now required or any explanation of the change on their
>> website. Not being overly familiar with either the Mercurial or jcheck
>> code, this may be the wrong approach, but it seems to be working so far
>> for me.
>>
> Ping?

From aeubanks at google.com  Mon May 13 17:43:39 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Mon, 13 May 2019 10:43:39 -0700
Subject: [RFR] 7902421: jcheck fails with mercurial 4.8
In-Reply-To: <cb7d2bb4-6a3d-7008-6193-2976c32294b5@oracle.com>
References: <9d5abe47-5408-6ebe-8e97-765396889adc@redhat.com>
 <8d02e6f4-7d13-144a-e954-fb96f103a45a@redhat.com>
 <cb7d2bb4-6a3d-7008-6193-2976c32294b5@oracle.com>
Message-ID: <CAPW48srqCTS+KqEJm+R1=Re_nVxMGMd65SjSXCZ9O5Bk3vwr1A@mail.gmail.com>

LGTM. Thanks for fixing this.

*From: *Erik Joelsson <erik.joelsson at oracle.com>
*Date: *Mon, May 13, 2019 at 10:42 AM
*To: *Andrew John Hughes, <code-tools-dev at openjdk.java.net>

Looks ok to me.
>
> /Erik
>
> On 2019-05-13 10:33, Andrew John Hughes wrote:
> >
> > On 22/03/2019 00:59, Andrew John Hughes wrote:
> >> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902421
> >> Webrev:
> https://cr.openjdk.java.net/~andrew/codetools/7902421/webrev.01/
> >>
> >> Mercurial pull requests started failing after upgrading to 4.8.1:
> >>
> >> File "/home/andrew/projects/openjdk/jcheck/jcheck.py", line 745, in hook
> >>      ch.check(repo.changelog.node(rev))
> >>    File "/home/andrew/projects/openjdk/jcheck/jcheck.py", line 688, in
> check
> >>      ctx = context.changectx(self.repo, node)
> >>
> >> This seems to be because context.changectx now takes an additional
> argument:
> >>
> >> ArgSpec(args=['self', 'repo', 'rev', 'node'], varargs=None,
> >> keywords=None, defaults=None)
> >>
> >> so I made changes to pass through the rev argument. This fixes the
> >> problem and I can pull in changes again.
> >>
> >> I couldn't see any clear mention in the Mercurial code of why this rev
> >> argument is now required or any explanation of the change on their
> >> website. Not being overly familiar with either the Mercurial or jcheck
> >> code, this may be the wrong approach, but it seems to be working so far
> >> for me.
> >>
> > Ping?
>

From gnu.andrew at redhat.com  Mon May 13 18:21:41 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 13 May 2019 19:21:41 +0100
Subject: [RFR] 7902421: jcheck fails with mercurial 4.8
In-Reply-To: <cb7d2bb4-6a3d-7008-6193-2976c32294b5@oracle.com>
References: <9d5abe47-5408-6ebe-8e97-765396889adc@redhat.com>
 <8d02e6f4-7d13-144a-e954-fb96f103a45a@redhat.com>
 <cb7d2bb4-6a3d-7008-6193-2976c32294b5@oracle.com>
Message-ID: <59bb1f6e-2e2d-4e24-b3c5-a6e32b5174e9@redhat.com>



On 13/05/2019 18:39, Erik Joelsson wrote:
> Looks ok to me.
> 
> /Erik
> 
> On 2019-05-13 10:33, Andrew John Hughes wrote:
>>
>> On 22/03/2019 00:59, Andrew John Hughes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902421
>>> Webrev: https://cr.openjdk.java.net/~andrew/codetools/7902421/webrev.01/
>>>
>>> Mercurial pull requests started failing after upgrading to 4.8.1:
>>>
>>> File "/home/andrew/projects/openjdk/jcheck/jcheck.py", line 745, in hook
>>> ???? ch.check(repo.changelog.node(rev))
>>> ?? File "/home/andrew/projects/openjdk/jcheck/jcheck.py", line 688,
>>> in check
>>> ???? ctx = context.changectx(self.repo, node)
>>>
>>> This seems to be because context.changectx now takes an additional
>>> argument:
>>>
>>> ArgSpec(args=['self', 'repo', 'rev', 'node'], varargs=None,
>>> keywords=None, defaults=None)
>>>
>>> so I made changes to pass through the rev argument. This fixes the
>>> problem and I can pull in changes again.
>>>
>>> I couldn't see any clear mention in the Mercurial code of why this rev
>>> argument is now required or any explanation of the change on their
>>> website. Not being overly familiar with either the Mercurial or jcheck
>>> code, this may be the wrong approach, but it seems to be working so far
>>> for me.
>>>
>> Ping?

Thanks.

Do I need an official reviewer from
https://openjdk.java.net/census#code-tools to ok this too or is the ok
from yourself & Arthur enough to push this?
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From alexandre.iline at oracle.com  Mon May 13 18:30:49 2019
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Mon, 13 May 2019 11:30:49 -0700
Subject: CFV: New Code Tools Committer: Abdul Muneer Kolarkunnu
Message-ID: <AF1ED00C-19F7-46D2-9D1E-A64966646DD8@oracle.com>

Hi,

I hereby nominate Abdul Muneer Kolarkunnu (akolarkunnu) to Code ToolsCommitter.

Muneer has been working in the Quality team at Oracle for last 3 years. He has been contributing to test development and stabilization. As part of that he has been enhancing Jemmy library. He has contributed 13 changes to the Code Tools Jemmy Project by now [0]. 
 
Votes are due by 1pm PDT, May 20, 2019. Only current Code Tools Committers [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
 
For Lazy Consensus voting instructions, see [2].
 
Alexander (Shura) Ilin

[0] http://hg.openjdk.java.net/code-tools/jemmy/v2/log?revcount=200&rev=(author(akolarkunnu)+or+desc(%22abdul.kolarkunnu%40oracle.com%22))+and+not+merge()
[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

From jonathan.gibbons at oracle.com  Mon May 13 18:33:06 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 13 May 2019 11:33:06 -0700
Subject: [RFR] 7902421: jcheck fails with mercurial 4.8
In-Reply-To: <59bb1f6e-2e2d-4e24-b3c5-a6e32b5174e9@redhat.com>
References: <9d5abe47-5408-6ebe-8e97-765396889adc@redhat.com>
 <8d02e6f4-7d13-144a-e954-fb96f103a45a@redhat.com>
 <cb7d2bb4-6a3d-7008-6193-2976c32294b5@oracle.com>
 <59bb1f6e-2e2d-4e24-b3c5-a6e32b5174e9@redhat.com>
Message-ID: <44abfb07-1b76-371d-7b08-00c617d49d6a@oracle.com>

Andrew,

Code Tools is not set up to require official "R"eviewers, and so it 
should be enough to have consensus from enough suitably-informed people 
who are familiar with the code in question.

IMO, jcheck is a somewhat special because because of how deeply it is 
embedded within the infrastructure, so we need to be extra careful about 
updates, but it does seem like that is consensus that this is a 
reasonable patch.

-- Jon


On 05/13/2019 11:21 AM, Andrew John Hughes wrote:
>
> On 13/05/2019 18:39, Erik Joelsson wrote:
>> Looks ok to me.
>>
>> /Erik
>>
>> On 2019-05-13 10:33, Andrew John Hughes wrote:
>>> On 22/03/2019 00:59, Andrew John Hughes wrote:
>>>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902421
>>>> Webrev: https://cr.openjdk.java.net/~andrew/codetools/7902421/webrev.01/
>>>>
>>>> Mercurial pull requests started failing after upgrading to 4.8.1:
>>>>
>>>> File "/home/andrew/projects/openjdk/jcheck/jcheck.py", line 745, in hook
>>>>  ???? ch.check(repo.changelog.node(rev))
>>>>  ?? File "/home/andrew/projects/openjdk/jcheck/jcheck.py", line 688,
>>>> in check
>>>>  ???? ctx = context.changectx(self.repo, node)
>>>>
>>>> This seems to be because context.changectx now takes an additional
>>>> argument:
>>>>
>>>> ArgSpec(args=['self', 'repo', 'rev', 'node'], varargs=None,
>>>> keywords=None, defaults=None)
>>>>
>>>> so I made changes to pass through the rev argument. This fixes the
>>>> problem and I can pull in changes again.
>>>>
>>>> I couldn't see any clear mention in the Mercurial code of why this rev
>>>> argument is now required or any explanation of the change on their
>>>> website. Not being overly familiar with either the Mercurial or jcheck
>>>> code, this may be the wrong approach, but it seems to be working so far
>>>> for me.
>>>>
>>> Ping?
> Thanks.
>
> Do I need an official reviewer from
> https://openjdk.java.net/census#code-tools to ok this too or is the ok
> from yourself & Arthur enough to push this?


From jonathan.gibbons at oracle.com  Mon May 13 18:36:08 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 13 May 2019 11:36:08 -0700
Subject: CFV: New Code Tools Committer: Abdul Muneer Kolarkunnu
In-Reply-To: <AF1ED00C-19F7-46D2-9D1E-A64966646DD8@oracle.com>
References: <AF1ED00C-19F7-46D2-9D1E-A64966646DD8@oracle.com>
Message-ID: <d4d24656-45b3-c5a5-c8cb-dac5ab27c4e7@oracle.com>

Shura,

This CFV has an invalid deadline of only one-week out.? Please resend 
the message, specifying two-week voting period.

Others,

Please wait to respond until Shura has sent out a corrected version of 
the message.

-- Jon

On 05/13/2019 11:30 AM, Alexandre (Shura) Iline wrote:
> Hi,
>
> I hereby nominate Abdul Muneer Kolarkunnu (akolarkunnu) to Code ToolsCommitter.
>
> Muneer has been working in the Quality team at Oracle for last 3 years. He has been contributing to test development and stabilization. As part of that he has been enhancing Jemmy library. He has contributed 13 changes to the Code Tools Jemmy Project by now [0].
>   
> Votes are due by 1pm PDT, May 20, 2019. Only current Code Tools Committers [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>   
> For Lazy Consensus voting instructions, see [2].
>   
> Alexander (Shura) Ilin
>
> [0] http://hg.openjdk.java.net/code-tools/jemmy/v2/log?revcount=200&rev=(author(akolarkunnu)+or+desc(%22abdul.kolarkunnu%40oracle.com%22))+and+not+merge()
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote


From alexandre.iline at oracle.com  Mon May 13 18:48:32 2019
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Mon, 13 May 2019 11:48:32 -0700
Subject: CFV: New Code Tools Committer: Abdul Muneer Kolarkunnu
Message-ID: <C0AA5E31-659A-40AC-AD26-15FE2439EC57@oracle.com>

Hi,

I hereby nominate Abdul Muneer Kolarkunnu (akolarkunnu) to Code ToolsCommitter.

Muneer has been working in the Quality team at Oracle for last 3 years. He has been contributing to test development and stabilization. As part of that he has been enhancing Jemmy library. He has contributed 13 changes to the Code Tools Jemmy Project by now [0]. 

Votes are due by 1pm PDT, May 27, 2019. 

Only current Code Tools Committers [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [2].

Alexander (Shura) Ilin

[0] http://hg.openjdk.java.net/code-tools/jemmy/v2/log?revcount=200&rev=(author(akolarkunnu)+or+desc(%22abdul.kolarkunnu%40oracle.com%22))+and+not+merge()
[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

From gnu.andrew at redhat.com  Tue May 28 22:00:38 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Tue, 28 May 2019 23:00:38 +0100
Subject: [RFR] 7902421: jcheck fails with mercurial 4.8
In-Reply-To: <44abfb07-1b76-371d-7b08-00c617d49d6a@oracle.com>
References: <9d5abe47-5408-6ebe-8e97-765396889adc@redhat.com>
 <8d02e6f4-7d13-144a-e954-fb96f103a45a@redhat.com>
 <cb7d2bb4-6a3d-7008-6193-2976c32294b5@oracle.com>
 <59bb1f6e-2e2d-4e24-b3c5-a6e32b5174e9@redhat.com>
 <44abfb07-1b76-371d-7b08-00c617d49d6a@oracle.com>
Message-ID: <0111a0f2-7035-e58a-10a4-50bf1dc59f41@redhat.com>



On 13/05/2019 19:33, Jonathan Gibbons wrote:
> Andrew,
> 
> Code Tools is not set up to require official "R"eviewers, and so it
> should be enough to have consensus from enough suitably-informed people
> who are familiar with the code in question.
> 
> IMO, jcheck is a somewhat special because because of how deeply it is
> embedded within the infrastructure, so we need to be extra careful about
> updates, but it does seem like that is consensus that this is a
> reasonable patch.
> 
> -- Jon
> 
> 

Thanks Jon.

I don't have commit access to push this myself, so maybe someone could
do so on my behalf. Maybe Aleksey? :-)

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From jonathan.gibbons at oracle.com  Wed May 29 00:35:07 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 28 May 2019 17:35:07 -0700
Subject: [RFR] 7902421: jcheck fails with mercurial 4.8
In-Reply-To: <0111a0f2-7035-e58a-10a4-50bf1dc59f41@redhat.com>
References: <9d5abe47-5408-6ebe-8e97-765396889adc@redhat.com>
 <8d02e6f4-7d13-144a-e954-fb96f103a45a@redhat.com>
 <cb7d2bb4-6a3d-7008-6193-2976c32294b5@oracle.com>
 <59bb1f6e-2e2d-4e24-b3c5-a6e32b5174e9@redhat.com>
 <44abfb07-1b76-371d-7b08-00c617d49d6a@oracle.com>
 <0111a0f2-7035-e58a-10a4-50bf1dc59f41@redhat.com>
Message-ID: <35b995cc-fa76-b259-a8aa-d5fafa7f448f@oracle.com>

Erik reviewed it and has commit rights.

Given that Erik reviewed it, I can sponsor it, but I would prefer to do 
so at the beginning of a work day instead of at the end of a work day: I 
don't want to "push and run".

I'll push the change tomorrow morning (Wed May 29) if no one else has 
already done so.

-- Jon

On 5/28/19 3:00 PM, Andrew John Hughes wrote:
>
> On 13/05/2019 19:33, Jonathan Gibbons wrote:
>> Andrew,
>>
>> Code Tools is not set up to require official "R"eviewers, and so it
>> should be enough to have consensus from enough suitably-informed people
>> who are familiar with the code in question.
>>
>> IMO, jcheck is a somewhat special because because of how deeply it is
>> embedded within the infrastructure, so we need to be extra careful about
>> updates, but it does seem like that is consensus that this is a
>> reasonable patch.
>>
>> -- Jon
>>
>>
> Thanks Jon.
>
> I don't have commit access to push this myself, so maybe someone could
> do so on my behalf. Maybe Aleksey? :-)
>
> Thanks,

From jonathan.gibbons at oracle.com  Wed May 29 17:26:50 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 29 May 2019 10:26:50 -0700
Subject: [RFR] 7902421: jcheck fails with mercurial 4.8
In-Reply-To: <35b995cc-fa76-b259-a8aa-d5fafa7f448f@oracle.com>
References: <9d5abe47-5408-6ebe-8e97-765396889adc@redhat.com>
 <8d02e6f4-7d13-144a-e954-fb96f103a45a@redhat.com>
 <cb7d2bb4-6a3d-7008-6193-2976c32294b5@oracle.com>
 <59bb1f6e-2e2d-4e24-b3c5-a6e32b5174e9@redhat.com>
 <44abfb07-1b76-371d-7b08-00c617d49d6a@oracle.com>
 <0111a0f2-7035-e58a-10a4-50bf1dc59f41@redhat.com>
 <35b995cc-fa76-b259-a8aa-d5fafa7f448f@oracle.com>
Message-ID: <f3d001d4-b694-e110-cf68-25f04ec89b55@oracle.com>

Pushed.

-- Jon


On 05/28/2019 05:35 PM, Jonathan Gibbons wrote:
> Erik reviewed it and has commit rights.
>
> Given that Erik reviewed it, I can sponsor it, but I would prefer to 
> do so at the beginning of a work day instead of at the end of a work 
> day: I don't want to "push and run".
>
> I'll push the change tomorrow morning (Wed May 29) if no one else has 
> already done so.
>
> -- Jon
>
> On 5/28/19 3:00 PM, Andrew John Hughes wrote:
>>
>> On 13/05/2019 19:33, Jonathan Gibbons wrote:
>>> Andrew,
>>>
>>> Code Tools is not set up to require official "R"eviewers, and so it
>>> should be enough to have consensus from enough suitably-informed people
>>> who are familiar with the code in question.
>>>
>>> IMO, jcheck is a somewhat special because because of how deeply it is
>>> embedded within the infrastructure, so we need to be extra careful 
>>> about
>>> updates, but it does seem like that is consensus that this is a
>>> reasonable patch.
>>>
>>> -- Jon
>>>
>>>
>> Thanks Jon.
>>
>> I don't have commit access to push this myself, so maybe someone could
>> do so on my behalf. Maybe Aleksey? :-)
>>
>> Thanks,