[Hyperledger Project TSC] [Hyperledger-fabric] [Decision needed] dealing with go import path post Gerrit migration


Brian Behlendorf
 

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.

Brian

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 github.com/hyperledger/fabric`
will automatically map `github.com/hyperledger/fabric` to `https://github.com/hyperledger/fabric.git`.

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 hyperledger.org/fabric. We could host our generated docs at that URL, hanging off of the hyperledger.org
domain and linked from say hyperledger.org/community and include the <meta> tag that informed
go where the corresponding git repo resides. e.g.:

    <meta name="go-import" content="example.org git https://gerrit.hyperledger.org/r/p/fabric">

We just need to include this meta tag in the HTML served up from https://hyperledger.org/fabric. 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 hyperledger.org/fabric`
would install the source at:
`$GOPATH/src/hyperledger.org/fabric`

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.

Thoughts?

[1] https://golang.org/cmd/go/#hdr-Remote_import_paths

Cheers,


Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric



--
Best wishes!
Baohua


_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric


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


Sheehan Anderson <sheehan@...>
 

Option 2 follows the path that the Go team uses. Go is developed in Gerrit, mirrored in GitHub, and uses golang.org for package names. I vote option 2 also.

-Sheehan

Brian Behlendorf via hyperledger-tsc ---08/01/2016 01:16:15 PM---I'm cc'ing the TSC, as I think this is something that affects the technical efforts project-wide, a

From: Brian Behlendorf via hyperledger-tsc <hyperledger-tsc@...>
To: hyperledger-fabric@..., hyperledger-tsc@...
Date: 08/01/2016 01:16 PM
Subject: Re: [Hyperledger Project TSC] [Hyperledger-fabric] [Decision needed] dealing with go import path post Gerrit migration
Sent by: hyperledger-tsc-bounces@...





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.

Brian

On 07/30/2016 04:37 AM, Baohua Yang wrote:

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



Baohua Yang
 

That causes issues of duplicated local dirs.

e.g., the go tools pkg, there're two repos under GOPATH. 


Some time you may get one tool from github, then another one from golang. 

Looks weird. :(

On Thu, Aug 4, 2016 at 3:29 AM, Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:

Option 2 follows the path that the Go team uses. Go is developed in Gerrit, mirrored in GitHub, and uses golang.org for package names. I vote option 2 also.

-Sheehan

Brian Behlendorf via hyperledger-tsc ---08/01/2016 01:16:15 PM---I'm cc'ing the TSC, as I think this is something that affects the technical efforts project-wide, a

From: Brian Behlendorf via hyperledger-tsc <hyperledger-tsc@...>
To: hyperledger-fabric@..., hyperledger-tsc@...
Date: 08/01/2016 01:16 PM
Subject: Re: [Hyperledger Project TSC] [Hyperledger-fabric] [Decision needed] dealing with go import path post Gerrit migration
Sent by: hyperledger-tsc-bounces@...





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.

Brian

On 07/30/2016 04:37 AM, Baohua Yang wrote:

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...

Twitter: @brianbehlendorf
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc




--
Best wishes!
Baohua


Andrew Bransford Brown <andrewbb@...>
 

I concur.  And I understand.

Double-sets of books.  Understanding hidden forks.

Andrew B. Brown
10723 River Plantation Drive
Austin, Texas  78747
(512) 947-8282


On Wed, Aug 3, 2016 at 7:45 PM, Baohua Yang via hyperledger-tsc <hyperledger-tsc@...> wrote:
That causes issues of duplicated local dirs.

e.g., the go tools pkg, there're two repos under GOPATH. 


Some time you may get one tool from github, then another one from golang. 

Looks weird. :(

On Thu, Aug 4, 2016 at 3:29 AM, Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:

Option 2 follows the path that the Go team uses. Go is developed in Gerrit, mirrored in GitHub, and uses golang.org for package names. I vote option 2 also.

-Sheehan

Brian Behlendorf via hyperledger-tsc ---08/01/2016 01:16:15 PM---I'm cc'ing the TSC, as I think this is something that affects the technical efforts project-wide, a

From: Brian Behlendorf via hyperledger-tsc <hyperledger-tsc@...>
To: hyperledger-fabric@..., hyperledger-tsc@...
Date: 08/01/2016 01:16 PM
Subject: Re: [Hyperledger Project TSC] [Hyperledger-fabric] [Decision needed] dealing with go import path post Gerrit migration
Sent by: hyperledger-tsc-bounces@...





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.

Brian

On 07/30/2016 04:37 AM, Baohua Yang wrote:

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...

Twitter: @brianbehlendorf
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc




--
Best wishes!
Baohua

_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc