Re: OpenJDK Community Code Review server rollout

View: New views
3 Messages — Rating Filter:   Alert me  

Parent Message unknown Re: OpenJDK Community Code Review server rollout

by tim.bell :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ivan:

> I'd like to use cr.openjdk.java.net for a public review.
> How to set/reset password to that site?

cr.openjdk.java.net is using the same ssh public key that you registered
  when you became a contributor to hg.openjdk.java.net.

> If it is the same is the as for openjdk.java.net I probably do not have
> the right permissions.

If you are not running ssh-agent, you should be prompted for your public
key passphrase.  For example:

% sftp cr.openjdk.java.net
Connecting to cr.openjdk.java.net...
Enter passphrase for key '/x/tbell/.ssh/id_dsa':


If you are getting a 'password' prompt, then something is wrong with the
  public key negotiations and you need to fix that first.

The extra-verbose output of 'sftp -vvv cr.openjdk.java.net' may help you
see where the public key handshaking breaks down.

Hope this helps-

Tim

Re: OpenJDK Community Code Review server rollout

by John Rose-6 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Thanks!  A couple of RFEs:

You mention webrev on the root page; can we have a link to it there,  
as there in your rollout Email?

The webrevs are not very portable in their expanded browsable state:  
There are too many files.  I'd like to see an option to upload or  
download a *tgz or *zip bundle as a unit.

It could be fairly simple, with just one bit of magic:  Have a private  
".bundles" subdirectory hierarchy with a background script watching  
it, like ".trashes".  Uploading to ".bundles" would cause the archive  
file to be unpacked (relative to top level).  Allow both ".bundles"  
"bundles" (w/ & w/o leading dot) also, so that the archive files  
themselves could be left out in public, for easy anonymous downloading.

-- John

P.S.  The old http://webrev.invokedynamic.info/ site did not supply  
rsync/scp/sftp, so I forced users to upload single *tgz or *zip files  
manually.  The virtue of this necessity was that the server uploaded  
the bundles as a unit and then unpacked them locally, saving lots of  
network handshakes.

Re: OpenJDK Community Code Review server rollout

by tim.bell :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

[Moving this thread to web-discuss (at) openjdk.java.net]

John Rose wrote:

> Thanks!  A couple of RFEs:

Thanks back.  BTW - I owe a lot to Dan Price and the OpenSolaris folks
for working out this code review server scheme - what I did was take
their layout and hook it up with our db.ojn server and authentication
scheme.  After we got a bunch of Legal approval and other
non-programming issues settled...

> You mention webrev on the root page; can we have a link to it there, as
> there in your rollout Email?

Yes, I will make that information more prominent on the page later
tonight.  Jessie (Jean-Christophe Collet) has been doing good work on
the webrev script lately, so you probably want to be running the latest
version:

   http://blogs.sun.com/jcc/
   http://blogs.sun.com/jcc/resource/webrev

> The webrevs are not very portable in their expanded browsable state:  
> There are too many files.  I'd like to see an option to upload or
> download a *tgz or *zip bundle as a unit.
>
> It could be fairly simple, with just one bit of magic:  Have a private
> ".bundles" subdirectory hierarchy with a background script watching it,
> like ".trashes".  Uploading to ".bundles" would cause the archive file
> to be unpacked (relative to top level).  Allow both ".bundles" "bundles"
> (w/ & w/o leading dot) also, so that the archive files themselves could
> be left out in public, for easy anonymous downloading.

Good idea, and not so hard to set up.  Does anyone else have an opinion
on this feature?  I will work on getting this up later this week.

Thanks for the feedback-

Tim

> P.S.  The old http://webrev.invokedynamic.info/ site did not supply
> rsync/scp/sftp, so I forced users to upload single *tgz or *zip files
> manually.  The virtue of this necessity was that the server uploaded the
> bundles as a unit and then unpacked them locally, saving lots of network
> handshakes.

Yes, that is true, although I don't notice a real bottleneck with the
network.  I typically start up a 'scp -r' and then go heat up some water
for tea...