Access to Gerrit Code Review sources + review
Shawn Pearce
ideal. I hate the current situation as much as the rest of you.
= Source Access =
There is a Git repository at https://code.google.com/p/gerrit/. You
can clone this repository to get Gerrit source code. You can browse it
through the source link in your web browser.
This repository used to be SVN and stored precompiled binaries of our
dependencies. It was converted last August to be a Git repository to
host our source code.
This repository is available to read without user authentication. You
do not need a password to access it.
This repository is often out of date by several days. Committers need
to manually synchronize it from the hidden review server. I just
pushed current master, stable, and the v2.2.2-rc0 tag.
= Binary Dependencies =
The binaries moved to
https://code.google.com/p/gerrit-maven-repository/ (which is SVN). The
Gerrit project uses this repository to store binaries of dependencies
that are not readily available from Maven Central. Libraries like JGit
(which Gerrit often depends on pre-release versions of), MINA SSHD
(which Gerrit has pegged to a specific pre-release version due to
integration work), gwtorm, PrologCafe, etc are hosted here for
Gerrit's use.
This repository is available to read without user authentication. You
do not need a password to access it.
= Gerrit Access =
There is a Gerrit Code Review server hidden at
https://gerrit-review.googlesource.com/. Due to the high number of
bugs this server has a small white-list access policy. You know if you
have access to it, because I told you I added you to the white-list.
Right now I am not really handing out access because the environment
is still too flaky.
I hope to be able to remove the white-list and open the server to
everyone in early January.
The repositories managed by this Gerrit Code Review server are also
available at https://gerrit.googlesource.com/ (notice the no -review
suffix). This infrastructure is stable, and could be made generally
available. Unfortunately the same white-list access policy controls
both gerrit-review.googlesource.com and gerrit.googlesource.com.
Making the latter generally available will also make the buggy review
server available, which I am not interested in doing right now.
For those who do have access, changes can be pushed for review:
https://gerrit-review.googlesource.com/p/gerrit
and fetched from either URL:
https://gerrit.googlesource.com/gerrit
https://gerrit-review.googlesource.com/p/gerrit
Yes this is confusing. Both URLs access the same repository. The
-review suffix on the hostname ensures requests route to the Gerrit
Code Review process, rather than to a farm of dumb Git servers that
have no Gerrit-aware functionality. The /p/ in the path is currently
required for Gerrit Code Review to recognize the request as a Git
request. This is a misfeature in the Gerrit Code Review project and
something I want to deprecate out. JGit now has the necessary filter
support, I just need to write the change in Gerrit to take advantage
of it.
Because of the white-list access policy, both of these URLs require a
password to identify and authorize the user. When things are stable
enough to be made generally available, reads will be anonymous (no
password required), and pushes to create/update changes will require
authentication (to ensure correct attribution).
Monty Taylor
On 12/21/2011 04:37 PM, Shawn Pearce wrote:
> Let me try to clarify the current project infrastructure. It is *NOT*
> ideal. I hate the current situation as much as the rest of you.
Thanks Shawn!
> = Source Access =
>
> There is a Git repository at https://code.google.com/p/gerrit/. You
> can clone this repository to get Gerrit source code. You can browse it
> through the source link in your web browser.
>
> This repository used to be SVN and stored precompiled binaries of our
> dependencies. It was converted last August to be a Git repository to
> host our source code.
>
> This repository is available to read without user authentication. You
> do not need a password to access it.
>
> This repository is often out of date by several days. Committers need
> to manually synchronize it from the hidden review server. I just
> pushed current master, stable, and the v2.2.2-rc0 tag.
This is killer helpful. (and also, the rebasing of my stuff from 2.2.1
was much less painful than I expected it was going to be. :) )
++