Great, pushed:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2cecdf7fbc90
Having the full changeset in the webrev was quite convenient. I was able to "hg
import" it directly.
s'marks
On 2/12/14 7:21 PM, Tristan Yan wrote:
Thank you Stuart
This is a very nice tutorial. I did try both ways. Adopt your fix doesn't seem
work for me. It still doesn't generate changeset. But without -r option works.
http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.02/
Could you push it for me?
Tristan
On 02/13/2014 03:48 AM, Stuart Marks wrote:
Hi Tristan,
Changes look good. Unfortunately the webrev doesn't contain an actual
changeset; it just contains a patch. In the webrev header there is the line
"Patch of Changes". Instead it should say "Changeset". Like this one:
http://cr.openjdk.java.net/~smarks/reviews/7900311/webrev.1/
Unfortunately webrev doesn't always produce an actual changeset, in particular
it doesn't if you use webrev -r.
(My example webrev above is a patch that changes webrev to generate the
changeset even with -r. It hasn't been pushed yet; possibly it will later
today. Or you can apply my webrev changeset to your local webrev.)
Or, you can just run webrev without -r and it should check "hg outgoing" to
determine the changesets used in generating the webrev, which does place the
changeset into the webrev.
Can you regenerate the webrev so that it includes the actual changeset? Sorry,
this is a small thing, but as someone who is sponsoring changesets, I'd
appreciate an actual changeset in the webrev instead of having to construct
one manually. I think other sponsors would appreciate this too.
s'marks
On 2/11/14 6:59 PM, Tristan Yan wrote:
Thank you Stuart
http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.01/
Regards
Tristan
On Feb 12, 2014, at 10:06 AM, Stuart Marks <stuart.ma...@oracle.com
<mailto:stuart.ma...@oracle.com>> wrote:
Hi, yes, I'll take this one.
It's slightly odd that this is creating filenames that already have "/" in
them (as opposed to File.separator) but since these files don't actually have
to exist, I suppose it doesn't really matter.
I'm not convinced that we actually have any evidence that /home/~user is
really causing the hang/timeout (either caused by the automounter hanging on
/home or LDAP or other nameservice lookup on ~user), but this is harmless, and
it'll fix the problem on the off chance that this really is the root cause.
Tristan, please update the test's @bug tag to add 8030844, create a changeset,
and create a webrev with the changeset in it (as opposed to a bare patch).
I'll then push it for you.
s'marks
On 2/10/14 4:08 AM, Alan Bateman wrote:
On 10/02/2014 10:57, Tristan Yan wrote:
Ping: Can anyone give a review on this.
Thank you
Tristan
Changing the test so that it doesn't try to /home/~user seems reasonable to
me.
Stuart - I see you've been sponsoring Tristan's updates to the RMI tests. Are
you going to take this one too?
-Alan
On Feb 6, 2014, at 5:13 PM, Tristan Yan<tristan....@oracle.com
<mailto:tristan....@oracle.com>> wrote:
Hi All
Please help to review a simple fix for
https://bugs.openjdk.java.net/browse/JDK-8030844
http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.00/.
Description:
Change replace a “/home/~user" folder with an test source path. Folder
“/home/~user” cause some problem whenever something wrong with the automount
filesystem or an username lookup problem.
Thank you
Tristan
