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


Brian Behlendorf <bbehlendorf@...>
 

Hi all; looks like Chris's reply in this thread never made it (at least not to the archives) so I'm passing it along again.  Chris is on vacation this week, so we will circle back with this next, though it does look like consensus is converging on option 1, and hopefully that means he and Ry can work together to implement it next week.  If you feel strongly one way or another please feel free to voice it.

Brian


---------- Forwarded message ----------
From: Christopher B Ferris <chrisfer@...>
Date: Fri, Jul 29, 2016 at 12:43 PM
Subject: Re: [Hyperledger-fabric] [Decision needed] dealing with go import path post Gerrit migration
To: rjones@...
Cc: hyperledger-fabric@...


resending - received a bounce
 
I hadn't meant to imply that we hd made a decision, sorry. I was seeking consensus, first.
 
However, I think transfer makes most sense when we do decide.
 
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
 
 

----- Original message -----
From: Ry Jones <rjones@...>
To: Christopher B Ferris/Waltham/IBM@IBMUS
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] [Decision needed] dealing with go import path post Gerrit migration
Date: Fri, Jul 29, 2016 1:53 PM
 
 
I have a questions about step 2. We can either transfer the projects, or copy them. The difference is where the existing forks, stars, and subscriptions end up. If we transfer, all of that goes along to the archive. The downside is people will have expressed interest in a read-only archive. If we copy it, the downside is once we force push to the current /hyperledger/fabric repo, anyone with forks or similar references will be lost in space - they'll be pointing to changes that no longer exist.
 
I prefer option 1, transfer the projects.
 
On Fri, Jul 29, 2016 at 10:12 AM, Christopher B Ferris <chrisfer@...> wrote:
I should note that we do intend to mirror Gerrit to GH to preserve the visibility, but we need to do some
work on that. Specifically, we need to
1. create a hyperledger-archives org
2. migrate hyperledger/fabric (and any subsequently migrated repos such as fabric-api) to hyperledger-archives
3. revise the corresponding README.md files to reflect that these are read-only archived repositories and pointing
to the current development repos in Gerrit.
4. implement Jenkins mirroring from Gerrit on successful merge build.

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-bounces@... wrote: -----To: hyperledger-fabric@...
From: Christopher B Ferris/Waltham/IBM@IBMUS
Sent by: hyperledger-fabric-bounces@...
Date: 07/29/2016 01:05PM
Subject: [Hyperledger-fabric] [Decision needed] dealing with go import path     post Gerrit migration

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


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


Join fabric@lists.hyperledger.org to automatically receive all group messages.