Re: [Decision needed] dealing with go import path post Gerrit migration

Brian Behlendorf <bbehlendorf@...>

I'm cc'ing the TSC, as I think this is something that affects the technical efforts project-wide, and should be decided as an HL standard (or at least intend towards one).  Follow-ups should probably be directed to the TSC list.

My preference would be for anything that reduces impediments to on-boarding new developers.  My secondary preference would be to leverage github when it adds value but avoid concentrating dependency or risk upon it.  For that, I think that means option 2 rather than option 1.


On 07/30/2016 04:37 AM, Baohua Yang wrote:
Option 1 should be more popular~

On Sat, Jul 30, 2016 at 1:05 AM, Christopher B Ferris <chrisfer@...> wrote:
There's a residual concern that lingers post the transition to Gerrit: namely, what to do about
go imports. gotools has rules that map automagically: e.g. `go get`
will automatically map `` to ``.

With the migration to Gerrit, we have a few options:

1) leverage the mirror of the fabric (and other) repos to GH and let nature take its course
2) leverage the ability to establish a non-GH identity for our project leveraging the <meta>
tage configuration supported by Go [1].

Option 1 is possibly least disruptive, but misleading and possibly confusing, as we really live
in Gerrit, not GH.

Option 2 actually allows us to establish our own identity. e.g. we could establish the package
as We could host our generated docs at that URL, hanging off of the
domain and linked from say and include the <meta> tag that informed
go where the corresponding git repo resides. e.g.:

    <meta name="go-import" content=" git">

We just need to include this meta tag in the HTML served up from I believe
we can do this, just need to dig a little on how we can either embed the readthedocs content (which
they support) or augment the metadata they publish by modifying the template (also supported I believe).

In any event, option 2 would yield the following:

`go get`
would install the source at:

This is a bit cleaner, and again, we have our own identity.

There are some doc changes needed to reflect this, and some tweaks to the devenv
setup, but personally, I prefer option 2.

Maintainers, please weigh in with your thoughts and indicate your preference. Others are
invited to do so as well. Of course, if there are better ideas out there, we welcome those
as well.




Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris


phone: +1 508 667 0402

Hyperledger-fabric mailing list

Best wishes!

Hyperledger-fabric mailing list

Brian Behlendorf
Executive Director at the Hyperledger Project
Twitter: @brianbehlendorf

Join to automatically receive all group messages.