From magnus.ihse.bursie at oracle.com Tue Jan 7 05:48:48 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 07 Jan 2014 14:48:48 +0100 Subject: Webrev in JBS In-Reply-To: <52B61DC1.8030305@oracle.com> References: <528DDBAF.7050309@oracle.com> <52B61DC1.8030305@oracle.com> Message-ID: <52CC05C0.3040905@oracle.com> On 2013-12-22 00:01, Stuart Marks wrote: > > Hi everybody, > > I've taken the liberty of moving these bugs. Thanks Stuart! > It's pretty simple. When viewing bug, go to the More Actions menu and > choose Move. It takes you through a little wizard to choose the new > project, new issue type, versions, components, etc. Aha. Thanks for the info. /Magnus From mike.duigou at oracle.com Tue Jan 7 10:37:27 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 7 Jan 2014 10:37:27 -0800 Subject: How will the webrev script in existing repos be updated? Message-ID: <99FD256D-C1AB-4FBE-9FA1-A3313A9BAF71@oracle.com> Hi all; I have been working on a patch in the JDK 9 repo, JDK-8029512, which I have now moved to CODETOOLS as CODETOOLS-7900304 (https://bugs.openjdk.java.net/browse/CODETOOLS-7900304). I am ready to push this change but curious what is supposed to happen afterwards. I would like to see the updated webrev pushed into jdk7u60, jdk8u20 and jdk9 repos. Second, can I get a sponsor for http://cr.openjdk.java.net/~mduigou/CODETOOLS-7900304/0/webrev/ ? As appropriate, a committer nomination would also be appreciated. Across CODETOOLS I have 8 changesets including 7900304; 5 in webrev and 3 in jtreg. Thanks Mike From stuart.marks at oracle.com Tue Jan 7 10:50:01 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 07 Jan 2014 10:50:01 -0800 Subject: How will the webrev script in existing repos be updated? In-Reply-To: <99FD256D-C1AB-4FBE-9FA1-A3313A9BAF71@oracle.com> References: <99FD256D-C1AB-4FBE-9FA1-A3313A9BAF71@oracle.com> Message-ID: <52CC4C59.9040203@oracle.com> On 1/7/14 10:37 AM, Mike Duigou wrote: > I have been working on a patch in the JDK 9 repo, JDK-8029512, which I have now moved to CODETOOLS as CODETOOLS-7900304 (https://bugs.openjdk.java.net/browse/CODETOOLS-7900304). I am ready to push this change but curious what is supposed to happen afterwards. I would like to see the updated webrev pushed into jdk7u60, jdk8u20 and jdk9 repos. Shouldn't we just remove webrev from the other repos? Either it'll have to be patched into each different release (more busywork) or it'll get out of date. Do the different releases have any different requirements on webrev? I hope not. I'd like to have one copy in CODETOOLS that everybody can use. There are probably README and wiki pages that need to be updated to point to the new location. s'marks From mike.duigou at oracle.com Tue Jan 7 10:58:59 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 7 Jan 2014 10:58:59 -0800 Subject: How will the webrev script in existing repos be updated? In-Reply-To: <52CC4C59.9040203@oracle.com> References: <99FD256D-C1AB-4FBE-9FA1-A3313A9BAF71@oracle.com> <52CC4C59.9040203@oracle.com> Message-ID: <0F2957B6-81EB-4430-A012-F29FE87E3037@oracle.com> On Jan 7 2014, at 10:50 , Stuart Marks wrote: > On 1/7/14 10:37 AM, Mike Duigou wrote: >> I have been working on a patch in the JDK 9 repo, JDK-8029512, which I have now moved to CODETOOLS as CODETOOLS-7900304 (https://bugs.openjdk.java.net/browse/CODETOOLS-7900304). I am ready to push this change but curious what is supposed to happen afterwards. I would like to see the updated webrev pushed into jdk7u60, jdk8u20 and jdk9 repos. > > Shouldn't we just remove webrev from the other repos? Either it'll have to be patched into each different release (more busywork) or it'll get out of date. Yes, busywork indeed. There are many places that the updated should be installed--every repo it appears in actually. > Do the different releases have any different requirements on webrev? No. Since they all try to generate links to the same bug database it's actually appropriate for all projects to be using the same version of webrev. > I hope not. I'd like to have one copy in CODETOOLS that everybody can use. Yep. Getting it to people is going to be the issue. I have heard grumblings about the annoyance of installing/updating jcheck locally. I suspect that with moving to CODETOOLS we are going to see more incidents of people using stale webrev again. It had been nice for a while in 8 that people were moving towards using the bundled up-to-date webrev rather than some hoary old version. Perhaps this might be a case where we can legitimately use mecurial sub-projects? > There are probably README and wiki pages that need to be updated to point to the new location. Yes. As you had to remind me just before the holiday break (and I promptly forgot), there is now a webrev project! I suspect that few people would find it on their own. Mike From jonathan.gibbons at oracle.com Tue Jan 7 11:19:28 2014 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 07 Jan 2014 19:19:28 +0000 Subject: hg: code-tools/webrev: 7900304: webrev.ksh: fix parsing of parent repo paths from hgrc file Message-ID: <20140107191928.2FEF562437@hg.openjdk.java.net> Changeset: 4993b0c5a9c6 Author: mduigou Date: 2014-01-07 10:16 -0800 URL: http://hg.openjdk.java.net/code-tools/webrev/rev/4993b0c5a9c6 7900304: webrev.ksh: fix parsing of parent repo paths from hgrc file Reviewed-by: erikj ! webrev.ksh From stuart.marks at oracle.com Tue Jan 7 11:36:41 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 07 Jan 2014 11:36:41 -0800 Subject: How will the webrev script in existing repos be updated? In-Reply-To: <0F2957B6-81EB-4430-A012-F29FE87E3037@oracle.com> References: <99FD256D-C1AB-4FBE-9FA1-A3313A9BAF71@oracle.com> <52CC4C59.9040203@oracle.com> <0F2957B6-81EB-4430-A012-F29FE87E3037@oracle.com> Message-ID: <52CC5749.6000101@oracle.com> On 1/7/14 10:58 AM, Mike Duigou wrote: > On Jan 7 2014, at 10:50 , Stuart Marks wrote: >> I'd like to have one copy in CODETOOLS that everybody can use. > > Yep. Getting it to people is going to be the issue. I have heard grumblings about the annoyance of installing/updating jcheck locally. I suspect that with moving to CODETOOLS we are going to see more incidents of people using stale webrev again. It had been nice for a while in 8 that people were moving towards using the bundled up-to-date webrev rather than some hoary old version. Perhaps this might be a case where we can legitimately use mecurial sub-projects? Fortunately webrev.ksh is just a single file, and it's easy enough to formulate a URL directly into the code-tools/webrev repo to get this one file: http://hg.openjdk.java.net/code-tools/webrev/raw-file/tip/webrev.ksh This at least avoids the rigamarole of having to clone yet another repo and keep it updated, just to get the latest webrev. I think this URL is safe to put into README files and wiki pages and such. s'marks From magnus.ihse.bursie at oracle.com Fri Jan 10 01:53:24 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 10 Jan 2014 10:53:24 +0100 Subject: New home for WebRev tool -- will be removed from jdk forest Message-ID: <52CFC314.9030802@oracle.com> The WebRev tool (webrev.ksh) have been moved to a separate repo in the code-tools project. This will make sure we have a single master copy, instead of several forks across all jdk versions. The copy of webrev currently located in the jdk forests (at /make/scripts/webrev.ksh) will be removed. To use webrev, please clone the webrev repo in a suitable location: hg clone http://hg.openjdk.java.net/code-tools/webrev It is possible to clone this repository inside a jdk forest, if you want. The hg forest extension will treat this repo as any other repo in the forest. The common/bin/hgforest.sh will not know about it, however, and you will need to update the repo manually if using that method. Since there exists multiple versions of the webrev script, the plan is to get the best part of them all and collect it into this master. If you have a locally modified version of webrev, please contact me so we can work out how to bring these enhancement to the master copy. If you want to report bugs on WebRev, please use the CODETOOLS project on JBS with the component tools and subcomponent webrev. For webrev development discussions, please use webrev-dev at openjdk.java.net. /Magnus From magnus.ihse.bursie at oracle.com Fri Jan 10 01:58:07 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 10 Jan 2014 10:58:07 +0100 Subject: Setting executable permissions? Message-ID: <52CFC42F.409@oracle.com> I understand that there is a ban on setting the executable bit on files in the JDK repositories. Does this ban extends to the codetools projects as well? In the case of webrev, there seems to be no good reason *not* to have the webrev.ksh file executable... Is there a formal requirement about this prohibition? Or is it "just" enforced by jcheck? /Magnus From jonathan.gibbons at oracle.com Fri Jan 10 11:38:49 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 10 Jan 2014 11:38:49 -0800 Subject: Setting executable permissions? In-Reply-To: <52CFC42F.409@oracle.com> References: <52CFC42F.409@oracle.com> Message-ID: <52D04C49.9060301@oracle.com> I guess I see that there is no good reason for code-tools projects to be any different from the convention for other OpenJDK projects. -- Jon On 01/10/2014 01:58 AM, Magnus Ihse Bursie wrote: > I understand that there is a ban on setting the executable bit on > files in the JDK repositories. > > Does this ban extends to the codetools projects as well? In the case > of webrev, there seems to be no good reason *not* to have the > webrev.ksh file executable... > > Is there a formal requirement about this prohibition? Or is it "just" > enforced by jcheck? > > /Magnus From volker.simonis at gmail.com Tue Jan 14 01:09:32 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 10:09:32 +0100 Subject: New home for WebRev tool -- will be removed from jdk forest In-Reply-To: <52CFC314.9030802@oracle.com> References: <52CFC314.9030802@oracle.com> Message-ID: Hi, I would appreciate if the "Bug id:" could be printed before the "Author comments:" as described in the patch below. The rational is that if he author comments are long (and I think we should encourage everybody to provide good explanations for its webrev) the link to the corresponding bug won't be visible in the header anymore. On the other hand, the "Bug id:" entry is guaranteed to always be just a single line. Regards, Volker diff -r 06dd913373b4 make/scripts/webrev.ksh --- a/make/scripts/webrev.ksh Wed Jan 08 11:20:09 2014 -0800 +++ b/make/scripts/webrev.ksh Tue Jan 14 10:03:56 2014 +0100 @@ -2600,11 +2600,6 @@ print "$WNAME.pdf" fi -if [[ -n "$iflag" ]]; then - print "Author comments:
" - cat /tmp/$$.include - print "
" -fi # Add links to referenced CRs, if any # URL has a like: # <title>[#JDK-8024688] b106-lambda: j.u.Map.merge doesn't work as specified if contains key:null pair - Java Bug System @@ -2631,6 +2626,13 @@ print "" done fi + +if [[ -n "$iflag" ]]; then + print "Author comments:
" + cat /tmp/$$.include + print "
" +fi + print "Legend:" print "Modified file
Deleted file
New file" print "" On Fri, Jan 10, 2014 at 10:53 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > The WebRev tool (webrev.ksh) have been moved to a separate repo in the > code-tools project. This will make sure we have a single master copy, > instead of several forks across all jdk versions. > > The copy of webrev currently located in the jdk forests (at > /make/scripts/webrev.ksh) will be removed. > > To use webrev, please clone the webrev repo in a suitable location: > hg clone http://hg.openjdk.java.net/code-tools/webrev > > It is possible to clone this repository inside a jdk forest, if you want. > The hg forest extension will treat this repo as any other repo in the > forest. The common/bin/hgforest.sh will not know about it, however, and you > will need to update the repo manually if using that method. > > Since there exists multiple versions of the webrev script, the plan is to > get the best part of them all and collect it into this master. If you have > a locally modified version of webrev, please contact me so we can work out > how to bring these enhancement to the master copy. > > If you want to report bugs on WebRev, please use the CODETOOLS project on > JBS with the component tools and subcomponent webrev. > > For webrev development discussions, please use webrev-dev at openjdk.java.net > . > > /Magnus > From stuart.marks at oracle.com Wed Jan 29 17:47:18 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 29 Jan 2014 17:47:18 -0800 Subject: RFR webrev: 7900311 webrev -r doesn't produce an exported changeset file In-Reply-To: <52B62279.5090603@oracle.com> References: <52B62279.5090603@oracle.com> Message-ID: <52E9AF26.7030309@oracle.com> I was frustrated today because webrev was producing a plain patch file instead of an exported changeset file. Then I realized I had run across this before. See message appended below. (Probably dropped because of the holidays.) I've filed https://bugs.openjdk.java.net/browse/CODETOOLS-7900311 for this. I've also run my modified webrev.ksh over this patch to webrev.ksh and have uploaded a webrev here: http://cr.openjdk.java.net/~smarks/reviews/7900311/webrev.0/ It's basically the same one-line change shown below. I don't think I have commit rights to the webrev repo; can someone push this for me? Two observations, independent of this change: a) Even though this is a one-line change, the sdiff and frames views show a lot of spurious segments of the file, with no apparent changes. b) The link in the changeset comment points to JDK-7900311, which doesn't exist, since the bug is actually CODETOOLS-7900311. Thanks, s'marks -------- Original Message -------- Subject: bug in webrev? export vs patch Date: Sat, 21 Dec 2013 15:21:29 -0800 From: Stuart Marks To: webrev-dev at openjdk.java.net CC: Mike Duigou Hi all, My typical workflow is to keep the changes I'm working on in MQ, and then generate a webrev based on the tipmost applied patch. Typically this is the only applied patch, so I use a command like webrev -N -r qparent to generate a webrev from this patch. Unfortunately, in this mode, webrev doesn't export the hg changeset, instead it just generates a patch. There's an actual changeset present, so it should export it, so I think that's a bug. (I guess I should file a CODETOOLS bug on this.) What to do about this? Well, I think there's a case in handling the -r flag where a bit more of the global state needs to be set. It correctly picks up the changeset comment but doesn't set the flag that eventually causes the changeset to be exported instead of a patch to be generated. I've tried this: diff -r 9eab6a0ae4b5 webrev.ksh --- a/webrev.ksh Fri Nov 08 09:36:55 2013 +0100 +++ b/webrev.ksh Sat Dec 21 15:11:40 2013 -0800 @@ -2008,6 +2008,7 @@ # FIRST_CREV=`hg log --rev $PARENT_REV --template '{rev}'` FIRST_CREV=`expr $FIRST_CREV + 1` + HG_LIST_FROM_COMMIT=1 fi fi #Let's check if a merge is needed, if so, issue a warning I haven't analyzed all the ways the various global variables are used though. However, using this patch "works for me" .... s'marks From mike.duigou at oracle.com Thu Jan 30 13:03:46 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 30 Jan 2014 13:03:46 -0800 Subject: RFR webrev: 7900311 webrev -r doesn't produce an exported changeset file In-Reply-To: <52E9AF26.7030309@oracle.com> References: <52B62279.5090603@oracle.com> <52E9AF26.7030309@oracle.com> Message-ID: <164F49E5-08C9-4EB0-9361-B7AAF882AFF6@oracle.com> On Jan 29 2014, at 17:47 , Stuart Marks wrote: > I was frustrated today because webrev was producing a plain patch file instead of an exported changeset file. Then I realized I had run across this before. See message appended below. (Probably dropped because of the holidays.) > > I've filed > > https://bugs.openjdk.java.net/browse/CODETOOLS-7900311 > > for this. I've also run my modified webrev.ksh over this patch to webrev.ksh and have uploaded a webrev here: > > http://cr.openjdk.java.net/~smarks/reviews/7900311/webrev.0/ > > It's basically the same one-line change shown below. I don't think I have commit rights to the webrev repo; can someone push this for me? Please bump the version number. > > Two observations, independent of this change: > > a) Even though this is a one-line change, the sdiff and frames views show a lot of spurious segments of the file, with no apparent changes. Quite odd. The udiff is in contrast nicely compact as is the actual changeset. > > b) The link in the changeset comment points to JDK-7900311, which doesn't exist, since the bug is actually CODETOOLS-7900311. The -c option needs to be extended to understand full bug ids. > > Thanks, > > s'marks > > > > -------- Original Message -------- > Subject: bug in webrev? export vs patch > Date: Sat, 21 Dec 2013 15:21:29 -0800 > From: Stuart Marks > To: webrev-dev at openjdk.java.net > CC: Mike Duigou > > Hi all, > > My typical workflow is to keep the changes I'm working on in MQ, and then > generate a webrev based on the tipmost applied patch. Typically this is the only > applied patch, so I use a command like > > webrev -N -r qparent > > to generate a webrev from this patch. Unfortunately, in this mode, webrev > doesn't export the hg changeset, instead it just generates a patch. There's an > actual changeset present, so it should export it, so I think that's a bug. > > (I guess I should file a CODETOOLS bug on this.) > > What to do about this? Well, I think there's a case in handling the -r flag > where a bit more of the global state needs to be set. It correctly picks up the > changeset comment but doesn't set the flag that eventually causes the changeset > to be exported instead of a patch to be generated. > > I've tried this: > > > diff -r 9eab6a0ae4b5 webrev.ksh > --- a/webrev.ksh Fri Nov 08 09:36:55 2013 +0100 > +++ b/webrev.ksh Sat Dec 21 15:11:40 2013 -0800 > @@ -2008,6 +2008,7 @@ > # > FIRST_CREV=`hg log --rev $PARENT_REV --template '{rev}'` > FIRST_CREV=`expr $FIRST_CREV + 1` > + HG_LIST_FROM_COMMIT=1 > fi > fi > #Let's check if a merge is needed, if so, issue a warning > > > I haven't analyzed all the ways the various global variables are used though. > However, using this patch "works for me" .... > > s'marks > > From stuart.marks at oracle.com Thu Jan 30 13:28:04 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 30 Jan 2014 13:28:04 -0800 Subject: RFR webrev: 7900311 webrev -r doesn't produce an exported changeset file In-Reply-To: <164F49E5-08C9-4EB0-9361-B7AAF882AFF6@oracle.com> References: <52B62279.5090603@oracle.com> <52E9AF26.7030309@oracle.com> <164F49E5-08C9-4EB0-9361-B7AAF882AFF6@oracle.com> Message-ID: <52EAC3E4.4020707@oracle.com> I've updated the version number and the copyright year as well. The patch has now tripled in size. :-) Updated webrev: http://cr.openjdk.java.net/~smarks/reviews/7900311/webrev.1/ s'marks On 1/30/14 1:03 PM, Mike Duigou wrote: > > On Jan 29 2014, at 17:47 , Stuart Marks wrote: > >> I was frustrated today because webrev was producing a plain patch file instead of an exported changeset file. Then I realized I had run across this before. See message appended below. (Probably dropped because of the holidays.) >> >> I've filed >> >> https://bugs.openjdk.java.net/browse/CODETOOLS-7900311 >> >> for this. I've also run my modified webrev.ksh over this patch to webrev.ksh and have uploaded a webrev here: >> >> http://cr.openjdk.java.net/~smarks/reviews/7900311/webrev.0/ >> >> It's basically the same one-line change shown below. I don't think I have commit rights to the webrev repo; can someone push this for me? > > Please bump the version number. > >> >> Two observations, independent of this change: >> >> a) Even though this is a one-line change, the sdiff and frames views show a lot of spurious segments of the file, with no apparent changes. > > Quite odd. The udiff is in contrast nicely compact as is the actual changeset. > >> >> b) The link in the changeset comment points to JDK-7900311, which doesn't exist, since the bug is actually CODETOOLS-7900311. > > The -c option needs to be extended to understand full bug ids. > >> >> Thanks, >> >> s'marks >> >> >> >> -------- Original Message -------- >> Subject: bug in webrev? export vs patch >> Date: Sat, 21 Dec 2013 15:21:29 -0800 >> From: Stuart Marks >> To: webrev-dev at openjdk.java.net >> CC: Mike Duigou >> >> Hi all, >> >> My typical workflow is to keep the changes I'm working on in MQ, and then >> generate a webrev based on the tipmost applied patch. Typically this is the only >> applied patch, so I use a command like >> >> webrev -N -r qparent >> >> to generate a webrev from this patch. Unfortunately, in this mode, webrev >> doesn't export the hg changeset, instead it just generates a patch. There's an >> actual changeset present, so it should export it, so I think that's a bug. >> >> (I guess I should file a CODETOOLS bug on this.) >> >> What to do about this? Well, I think there's a case in handling the -r flag >> where a bit more of the global state needs to be set. It correctly picks up the >> changeset comment but doesn't set the flag that eventually causes the changeset >> to be exported instead of a patch to be generated. >> >> I've tried this: >> >> >> diff -r 9eab6a0ae4b5 webrev.ksh >> --- a/webrev.ksh Fri Nov 08 09:36:55 2013 +0100 >> +++ b/webrev.ksh Sat Dec 21 15:11:40 2013 -0800 >> @@ -2008,6 +2008,7 @@ >> # >> FIRST_CREV=`hg log --rev $PARENT_REV --template '{rev}'` >> FIRST_CREV=`expr $FIRST_CREV + 1` >> + HG_LIST_FROM_COMMIT=1 >> fi >> fi >> #Let's check if a merge is needed, if so, issue a warning >> >> >> I haven't analyzed all the ways the various global variables are used though. >> However, using this patch "works for me" .... >> >> s'marks >> >> >