From mark.reinhold at oracle.com Mon Mar 5 20:21:59 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 05 Mar 2018 12:21:59 -0800 Subject: Oldest supported version of Mercurial? Message-ID: <20180305122159.943477119@eggemoggin.niobe.net> I'm working to upgrade the trees extension to run on the latest version of Mercurial (4.5). We've accumulated a number of hacky workarounds to support older versions, all the way back to Mercurial 1.1, and more such hacks would be needed to cope with recent (>= 4.2) changes to Mercurial's internal API. Is it time to drop some of these older workarounds? Would it be okay for the trees extension (and possibly others) only to work with, say, Mercurial 2.2 and later? (2.2 shipped on 2012/5/1, almost six years ago.) - Mark From martinrb at google.com Tue Mar 6 17:34:01 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 6 Mar 2018 09:34:01 -0800 Subject: Oldest supported version of Mercurial? In-Reply-To: <20180305122159.943477119@eggemoggin.niobe.net> References: <20180305122159.943477119@eggemoggin.niobe.net> Message-ID: Compatibility is less important for developers than other users. A useful comparison point is the version provided on various OSes. The oldest supported Ubuntu LTS is 14.04 and comes with mercurial 2.8. Thanks for maintaining trees - I'm a happy user. On Mon, Mar 5, 2018 at 12:21 PM, wrote: > I'm working to upgrade the trees extension to run on the latest version > of Mercurial (4.5). > > We've accumulated a number of hacky workarounds to support older > versions, all the way back to Mercurial 1.1, and more such hacks would > be needed to cope with recent (>= 4.2) changes to Mercurial's internal > API. > > Is it time to drop some of these older workarounds? Would it be okay > for the trees extension (and possibly others) only to work with, say, > Mercurial 2.2 and later? (2.2 shipped on 2012/5/1, almost six years > ago.) > > - Mark > From mark.reinhold at oracle.com Tue Mar 6 21:13:16 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 06 Mar 2018 13:13:16 -0800 Subject: RFR Mercurial trees extension: Fixes for hg 4.2-4.5 Message-ID: <20180306131316.288726455@eggemoggin.niobe.net> http://cr.openjdk.java.net/~mr/rev/trees/ Tested against hg 1.1-4.5, including remote tests. Question: In some of the code-tools repos, some changeset comments include bug numbers from the CODETOOLS JBS project. A couple of the recent changesets in the trees repo have bug numbers, but the most recent one does not. Do we want to use CODETOOLS bug numbers in the trees repo uniformly, going forward? What about other hg-tools repos? Personally, it seems like overkill to me since these tools are small, and usually change only rarely, but I'd like to hear other opinions. - Mark From iris.clark at oracle.com Tue Mar 6 22:04:19 2018 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 6 Mar 2018 14:04:19 -0800 (PST) Subject: RFR Mercurial trees extension: Fixes for hg 4.2-4.5 In-Reply-To: <20180306131316.288726455@eggemoggin.niobe.net> References: <20180306131316.288726455@eggemoggin.niobe.net> Message-ID: <9334113c-721e-4530-b81a-1db89faecd53@default> Hi, Mark. > http://cr.openjdk.java.net/~mr/rev/trees/ I am not a trees expert, but your changes look fine to me. > Do we want to use CODETOOLS bug numbers in the trees repo uniformly, going forward? > What about other hg-tools repos? I'm for making it easy to maintain these tools. If a bugid exists, then sure, use it for the commit. If there is no bugid, I don't think one should be created. The changeset itself should contain sufficient information to determine why the change was required. Thanks, iris From vladimir.kozlov at oracle.com Wed Mar 7 00:06:32 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 6 Mar 2018 16:06:32 -0800 Subject: Oldest supported version of Mercurial? Message-ID: From my (Hotspot developer in Oracle) POV it is safe to support only 2.2 and later. Lowest version on our machines I saw was 2.2.1. Tools we use in Oracle require at least Mercurial 3.2. I recently have to update 2.2 version I had on my machine. -- Thanks, Vladimir From erik.helin at oracle.com Wed Mar 7 11:13:17 2018 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 7 Mar 2018 12:13:17 +0100 Subject: RFR Mercurial trees extension: Fixes for hg 4.2-4.5 In-Reply-To: <20180306131316.288726455@eggemoggin.niobe.net> References: <20180306131316.288726455@eggemoggin.niobe.net> Message-ID: <3bb47aca-fdbd-a78d-b564-bef04f6814b7@oracle.com> On 03/06/2018 10:13 PM, mark.reinhold at oracle.com wrote: > http://cr.openjdk.java.net/~mr/rev/trees/ Looks good to me, reviewed. On 03/06/2018 10:13 PM, mark.reinhold at oracle.com wrote: > Question: In some of the code-tools repos, some changeset comments > include bug numbers from the CODETOOLS JBS project. A couple of the > recent changesets in the trees repo have bug numbers, but the most > recent one does not. > > Do we want to use CODETOOLS bug numbers in the trees repo uniformly, > going forward? What about other hg-tools repos? I would prefer not having to use bug numbers and instead rely on informative commit messages. If there already is a bug filed, and a patch solves that particular bug, then it seems good to include the bug number in the commit message. Thanks, Erik From mark.reinhold at oracle.com Wed Mar 7 19:55:02 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 07 Mar 2018 11:55:02 -0800 Subject: RFR jcheck: Miscellanous fixes Message-ID: <20180307115502.717582228@eggemoggin.niobe.net> http://cr.openjdk.java.net/~mr/rev/jcheck/ Miscellanous fixes to improve performance and testability, and to disallow the use of "duke" as a reviewer name. Tested against hg 2.2 2.9 3.{0..9} 4.{0..5}. - Mark From vladimir.kozlov at oracle.com Wed Mar 7 20:41:13 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Mar 2018 12:41:13 -0800 Subject: RFR jcheck: Miscellanous fixes In-Reply-To: <20180307115502.717582228@eggemoggin.niobe.net> References: <20180307115502.717582228@eggemoggin.niobe.net> Message-ID: Hi Mark, Which JDK releases are covered by new changesets whitelist? Should we prevent use of "duke" for user's id? Are we using it intentionally?: changeset: 47215:4ebc2e2fb97c user: duke date: Sat Sep 09 14:36:53 2017 +0200 summary: Added tag jdk-10+23 for changeset 22850b3a5524 I understand that it is hard to do it now since we have a lot of such entries: $ hg log |grep "user: duke" ttt |wc 3829 7658 68922 Is it possible to only check on 'commit' and 'push' commands? Thanks, Vladimir On 3/7/18 11:55 AM, mark.reinhold at oracle.com wrote: > http://cr.openjdk.java.net/~mr/rev/jcheck/ > > Miscellanous fixes to improve performance and testability, > and to disallow the use of "duke" as a reviewer name. > > Tested against hg 2.2 2.9 3.{0..9} 4.{0..5}. > > - Mark > From mark.reinhold at oracle.com Wed Mar 7 21:37:40 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 07 Mar 2018 13:37:40 -0800 Subject: RFR jcheck: Miscellanous fixes In-Reply-To: References: <20180307115502.717582228@eggemoggin.niobe.net> Message-ID: <20180307133740.466972764@eggemoggin.niobe.net> 2018/3/7 12:41:13 -0800, vladimir.kozlov at oracle.com: > Which JDK releases are covered by new changesets whitelist? All of them. > Should we prevent use of "duke" for user's id? Are we using it > intentionally?: > > changeset: 47215:4ebc2e2fb97c > user: duke > date: Sat Sep 09 14:36:53 2017 +0200 > summary: Added tag jdk-10+23 for changeset 22850b3a5524 > > I understand that it is hard to do it now since we have a lot of such > entries: > > $ hg log |grep "user: duke" ttt |wc > 3829 7658 68922 "duke" as a changeset author has been used intentionally in certain rare cases: For merge changesets introduced by the repository-consolidation project, for initial repository loads, and for some build tags. So far "duke" as a user hasn't been abused, so I'm not sure it's worth trying to protect it. "duke" as a reviewer has crept in because some developers list "duke" as a temporary reviewer when they first create a changeset comment, and then forget to put in the actual reviewers before they push. > Is it possible to only check on 'commit' and 'push' commands? Do you mean locally, or on the server? Locally, if you enable the hooks then jcheck will validate changesets that come in via hg push, pull, or unbundle (pretxnchangegroup) or via the commit command (pretxncommit). Both types of hooks are enabled on our hg servers. - Mark From vladimir.kozlov at oracle.com Wed Mar 7 22:26:45 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Mar 2018 14:26:45 -0800 Subject: RFR jcheck: Miscellanous fixes In-Reply-To: <20180307133740.466972764@eggemoggin.niobe.net> References: <20180307115502.717582228@eggemoggin.niobe.net> <20180307133740.466972764@eggemoggin.niobe.net> Message-ID: <24c66105-52ad-db6d-9efc-ba43872cbd44@oracle.com> On 3/7/18 1:37 PM, mark.reinhold at oracle.com wrote: > 2018/3/7 12:41:13 -0800, vladimir.kozlov at oracle.com: >> Which JDK releases are covered by new changesets whitelist? > > All of them. Good. I thought we have more then 11 in all releases. > >> Should we prevent use of "duke" for user's id? Are we using it >> intentionally?: >> >> changeset: 47215:4ebc2e2fb97c >> user: duke >> date: Sat Sep 09 14:36:53 2017 +0200 >> summary: Added tag jdk-10+23 for changeset 22850b3a5524 >> >> I understand that it is hard to do it now since we have a lot of such >> entries: >> >> $ hg log |grep "user: duke" ttt |wc >> 3829 7658 68922 > > "duke" as a changeset author has been used intentionally in certain rare > cases: For merge changesets introduced by the repository-consolidation > project, for initial repository loads, and for some build tags. So far > "duke" as a user hasn't been abused, so I'm not sure it's worth trying > to protect it. Okay. > > "duke" as a reviewer has crept in because some developers list "duke" > as a temporary reviewer when they first create a changeset comment, > and then forget to put in the actual reviewers before they push. Yes, that is the main reason. > >> Is it possible to only check on 'commit' and 'push' commands? > > Do you mean locally, or on the server? I mean, to list all invalid changesets in tool's code is not sustainable in long run. I thought may be there is a way to check only new changesets. For example add a special tag and check only after it. Or only check on commit on local machine and push on server side. Thanks, Vladimir > > Locally, if you enable the hooks then jcheck will validate changesets > that come in via hg push, pull, or unbundle (pretxnchangegroup) or via > the commit command (pretxncommit). > > Both types of hooks are enabled on our hg servers. > > - Mark >