We're moving to GitHub

[Rob Pike]

Go contributors,

When Go became an open source project 5 years ago, Mercurial was the best choice for us for a number of reasons, most important being the ability to support our choice of code review system.

Mercurial has served us well, but it's time to move on. The world today is quite different from the world then. Most members of the Go community use Git and host their work on GitHub, and we should join them. Thanks to the efforts of open source projects like Android, we now have access to a Git-based code review system that fits our workflow.

We are therefore pleased to announce that we plan to migrate the Go project and its subrepositories to GitHub. The issue tracker and the wiki will also be moved; all data will be preserved. We will use a Google-hosted instance of Gerrit for code reviews.

The transition will happen soon after the 1.4 release in early December. All development for 1.5 will happen in GitHub; the Mercurial tree will be closed to changes after the 1.4 release.

We are still developing the plan and will explain more about the transition in the coming weeks.

There is one thing we need to do beforehand, which is to gather the permissions necessary to migrate the issues on the issue tracker. If you have added issues or comments to the Go issue tracker, please visit go-issue-migrator.appspot.com and click on the "Yes, let's do this" button and authorize our migrator application on GitHub. This gives us access to your GitHub account to enable us to re-create your issues and comments as you, so that you will be notified of changes to issues you've contributed to. (It's OK to not give us this permission; if you don't, your issues and comments will be owned by a "gopherbot" account but will still be attributed to you.) We only need your credentials for the transition; once it's done we'll throw them away and—to be sure—you may revoke the token yourself.

As always, our thanks to the community for all the work you do to make Go succeed.

Rob

P.S. For those keeping score, this will be Go version control system number four. Go development started in Subversion, moved to Perforce, then Mercurial, and soon to Git.

[Dave Cheney]

What a wonderful surprise!

Although I never had many difficulties with the hg contribution scheme
I know that many found it foreign and felt that it was a hurdle to
contribution.

What a fantastic gesture to the Go community, and may it continue to
attract contributors to the project.

Dave

> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Brian Ketelsen]

Fantastic news. This is the best birthday present ever.

[jrba...@gmail.com]

Awesome. The percentage chance I submit bug fixes is approaching 100.

Great news.

Cheers,

John

[tufanbari...@gmail.com]

why does your github application want to see my all (public and private) repositories?

[Qian Qiao]

This is a great move, and fantastic news.

Only questions I have is: are you guys open to any other code review tools, although gerrit has had great success with the Android project, I've always felt that its UI is a little cumbersome.

Thanks,

-- Joe

[Caleb Spare]

Really great news!

A concern about the issue migrator app -- on the Github side of
things, it asks for total account permissions:

> This application will be able to read and write all public and private repo data.

Is it possible to use lower/more finely-grained permissions?
Presumably the issue migrator only needs to create issues and comments
on the behalf of users.

-Caleb

[Andrew Gerrand]

Nope, there's no way for us to ask for a narrower scope. :-(

> email to golang-dev+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.

[Brad Fitzpatrick]

Yup, sorry. We tried.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

[andrey mirtchovski]

Congratulations!

A small favour to ask: while you've got full permissions to my repos,
can you please fix my bugs? Thanks in advance! ;)

Signed: Cheeky

>> > email to golang-dev+...@googlegroups.com.

>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to golang-dev+...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to golang-dev+...@googlegroups.com.

[dga]

For the paranoid among us -- could you put an entry on the official golang website with a direct link to the appspot migrator?

> email to golang-dev+...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

[Brad Fitzpatrick]

It's real. Three of our email accounts didn't get owned.

[Andrew Gerrand]

And Twitter

[james4k]

If you have posted issues/comments with more than one Google account, will the migrator map them all to a single GitHub account, assuming you have OKed each account?

[Brad Fitzpatrick]

Just what somebody whose email account was owned would say!

Your twitter was probably password-reset using your owned email account!

[Brad Fitzpatrick]

Yes. Use the migrator approval flow for each of your emails. And if you can't do one of them, email us details and we'll hardcode it.

[Wael M. Nasreddine]

Fantastic news! Thank you Go team!

May I ask, what were the reasons to choose Gerrit for code reviews rather than adopting Github's way of Pull request and Code reviews?

- Wael

[Brendan Tracey]

Will Gerrit link in with golang-codereviews, or is that group going to cease to function/function differently? 

[Brad Fitzpatrick]

See replies here:  https://news.ycombinator.com/item?id=8605242

[chai2010]

Great news!

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

https://github.com/chai2010

[Dmitri Shuralyov]

Mercurial has served us well, but it's time to move on. The world today is quite different from the world then. Most members of the Go community use Git and host their work on GitHub, and we should join them.

This is such incredibly good news! What a surprise! Thank you!

I was just dreaming of this happening someday... a day ago, see https://twitter.com/shurcooL/status/532661104187412480.

I still can't believe this is real. This is very exciting, thank you once again!

[Nathan Youngman]

Thanks for making this change. Mercurial is pretty nice, but I think this will open the floodgates of contributions. That's a good thing, right? :-)

Who's heading up the Wiki migration? Besides the MoinMoin-ish to Markdown switch, I imagine each page will need to be checked over to ensure links are updated and everything works. I'd be happy to help whomever is taking this on.

For the Issue migration, I'm surprised that it's not possible to get permission to just public repositories. I trust the Go Team, but whether or not my workplace wants too is another question. I guess "gopherbot" is an option for anyone with reservations.

> "Applications can request access for either public or private repositories on a user-wide level."

[Robert Hao]

Great news! Especially China Gopher!

[Andrew Gerrand]

I have a tool to automate the wiki migration, but the content will need to be reviewed once the switch has been made. I'd appreciate your help when the time comes. Thank you!

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.

[bre...@gmail.com]

This is fantastic news! Thanks!

[meta keule]

Great news!

Will the Go sub repositories golang.org/x/* also move to github?
I hope so...

[Andrew Gerrand]

Yep, the subrepos will move too.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

[Caleb Spare]

Presumably the 'vanity' golang.org/x addresses will remain canonical.

[Andrew Gerrand]

Correct.

>> email to golang-dev+unsubscribe@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to golang-dev+unsubscribe@googlegroups.com.

[小菜]

good！

好消息！

在 2014年11月14日星期五UTC+8上午8时46分10秒，Rob Pike写道：

[David Symonds]

On 14 November 2014 11:57, <tufanbari...@gmail.com> wrote:

> why does your github application want to see my all (public and private) repositories?

Unfortunately that's the only granularity level that this GitHub
authorisation system permits. It's an all-or-nothing.

[Brad Fitzpatrick]

Because they didn't let us request finer grained privileges for the calls we needed.

On Nov 13, 2014 7:59 PM, <tufanbari...@gmail.com> wrote:

why does your github application want to see my all (public and private) repositories?

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

[Dmitri Shuralyov]

Just curious, but have you tried contacting their support to ask if anything can be done about finer grained privileges? Perhaps it's viable for them to add support for what's needed in time for you to use it.

One of the advantages of GitHub is that they can move relatively fast sometimes, so there's some chance it would pay off to try.

[Simon Whitehead]

My god this is amazing and will definitely increase my contributions past 1.

[Brad Fitzpatrick]

I did ask them questions but have not heard back anything yet.

[Henrik Johansson]

Super cool!

[Brad Fitzpatrick]

Have you been sitting on bug fixes for five years without telling us? :)

Hopefully you filed bugs at least!

On Thu, Nov 13, 2014 at 4:56 PM, <jrba...@gmail.com> wrote:

Awesome. The percentage chance I submit bug fixes is approaching 100.

Great news.

Cheers,

John

On Friday, November 14, 2014 11:51:44 AM UTC+11, Dave Cheney wrote:

What a wonderful surprise!

Although I never had many difficulties with the hg contribution scheme
I know that many found it foreign and felt that it was a hurdle to
contribution.

What a fantastic gesture to the Go community, and may it continue to
attract contributors to the project.

Dave

> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Qian Qiao]

On Thu Nov 13 2014 at 7:46:08 PM Rob Pike <r...@golang.org> wrote:

<snip>

 

P.S. For those keeping score, this will be Go version control system number four. Go development started in Subversion, moved to Perforce, then Mercurial, and soon to Git.

And maybe one day some nextgen version control system written in Go.

I for one wouldn't bet against it. 

[Hein Meling]

Wonderful news! Looking forward to this move!

Hein :)

[anac...@gmail.com]

Am I the only one that prefers Mercurial to Git? Are there any reasons motivating this other than the greater popularity of Git? Is it because GitHub does not support Mercurial?

[David du Colombier]

While I think moving to Git and Gerrit is a very good
thing, I feel a bit concerned about the builders.

Will the builders be required to run Git? Is there any
plan to modify the builder program to propose alternative
retrieving methods, like downloading the changeset archives
through HTTP?

Thanks.

--
David du Colombier

[Carl]

Git. Go. Gerrit. Google. Gmail. Github.

Good things come in Gs.

[David Symonds]

On 14 Nov 2014 18:01, "David du Colombier" <0in...@gmail.com> wrote:

> Will the builders be required to run Git? Is there any
> plan to modify the builder program to propose alternative
> retrieving methods, like downloading the changeset archives
> through HTTP?

GitHub serves repositories over HTTP, but we will probably try to make native Git work since it is much more efficient.

[Sebastien Douche]

On Fri, Nov 14, 2014 at 8:01 AM, David du Colombier <0in...@gmail.com> wrote:
> Will the builders be required to run Git? Is there any
> plan to modify the builder program to propose alternative
> retrieving methods, like downloading the changeset archives
> through HTTP?

GitHub serves over https and ssh:
https://help.github.com/articles/which-remote-url-should-i-use/


--
Sebastien Douche <sdo...@gmail.com>
Twitter: @sdouche / G+: +sdouche

[Jan Mercl]

On Fri, Nov 14, 2014 at 1:45 AM, Rob Pike <r...@golang.org> wrote:
> We are therefore pleased to announce that we plan to migrate the Go project
> and its subrepositories to GitHub.

The move from mercurial to git is welcome. However, code.google.com
supports git for a long time, so why not just switch the repository
format?

-j

[David Symonds]

On 14 November 2014 18:43, Jan Mercl <0xj...@gmail.com> wrote:

> The move from mercurial to git is welcome. However, code.google.com
> supports git for a long time, so why not just switch the repository
> format?

Rob answered that in the paragraph immediately preceding the one you quoted.

[Aram Hăvărneanu]

I am happy with this change, although it will mean we will have to
port git to Plan 9. Presumably we can hack the Plan 9 builders to get
the source somehow, but we still want to be able to do development on
Plan 9, so we need some sort of git on Plan 9.

--
Aram Hăvărneanu

[m...@looplab.se]

Awesome news! Very positive for the development of the language!

On Friday, November 14, 2014 1:46:10 AM UTC+1, Rob Pike wrote:

Go contributors,

When Go became an open source project 5 years ago, Mercurial was the best choice for us for a number of reasons, most important being the ability to support our choice of code review system.

Mercurial has served us well, but it's time to move on. The world today is quite different from the world then. Most members of the Go community use Git and host their work on GitHub, and we should join them. Thanks to the efforts of open source projects like Android, we now have access to a Git-based code review system that fits our workflow.

We are therefore pleased to announce that we plan to migrate the Go project and its subrepositories to GitHub. The issue tracker and the wiki will also be moved; all data will be preserved. We will use a Google-hosted instance of Gerrit for code reviews.

The transition will happen soon after the 1.4 release in early December. All development for 1.5 will happen in GitHub; the Mercurial tree will be closed to changes after the 1.4 release.

We are still developing the plan and will explain more about the transition in the coming weeks.

There is one thing we need to do beforehand, which is to gather the permissions necessary to migrate the issues on the issue tracker. If you have added issues or comments to the Go issue tracker, please visit go-issue-migrator.appspot.com and click on the "Yes, let's do this" button and authorize our migrator application on GitHub. This gives us access to your GitHub account to enable us to re-create your issues and comments as you, so that you will be notified of changes to issues you've contributed to. (It's OK to not give us this permission; if you don't, your issues and comments will be owned by a "gopherbot" account but will still be attributed to you.) We only need your credentials for the transition; once it's done we'll throw them away and—to be sure—you may revoke the token yourself.

As always, our thanks to the community for all the work you do to make Go succeed.

Rob

[David Symonds]

That's probably good anyway, assuming you'll want to contribute from
Plan 9 too, but if that's intractable then fetching
https://github.com/golang/go/archive/<ref>.tar.gz
(https://developer.github.com/v3/repos/contents/#get-archive-link)
will work as a substitute for builders. You've got a working tar and
gunzip, I presume? ;-)

[Jan Mercl]

On Fri, Nov 14, 2014 at 8:51 AM, David Symonds <dsym...@golang.org> wrote:
>> The move from mercurial to git is welcome. However, code.google.com
>> supports git for a long time, so why not just switch the repository
>> format?
>
> Rob answered that in the paragraph immediately preceding the one you quoted.

Rob wrote why X. The question is why not Y. If that perhaps seems to
some as the same then I probably can't help.

Sometimes asking why not Y helps to improve a solution to a problem;
there's nothing wrong in such questions.

-j

[debia...@gmail.com]

Wow! That's great! Excellent

Wow! That's great! Excellent

[debia...@gmail.com]

Wow ! That's great! Excellent

[robert...@gmail.com]

On Friday, November 14, 2014 1:07:04 AM UTC, Caleb Spare wrote:

Is it possible to use lower/more finely-grained permissions?
Presumably the issue migrator only needs to create issues and comments
on the behalf of users.

Currently the go-issue-migrator app is asking for the 'user' & 'repo' OAuth scopes - and the 'repo' scope is the one that seems a little odd, because I'd have expected the 'public_repo' scope to be adequate:

public_repo	Grants read/write access to code, commit statuses, and deployment statuses for public repositories and organizations.
repo	Grants read/write access to code, commit statuses, and deployment statuses for public and private repositories and organizations.

https://developer.github.com/v3/oauth/#scopes

The only documented difference between the public_repo and repo scopes is that the 'repo' scope allows read/write access to the users private repos.

So, if the 'repo' scope is required, I would guess that there are private Go repositories that will be hosted under https://github.com/golang. Presumably not all Go contributors will have access to the private repo(s) - if the authors of the go-issue-migrator tool wanted to finesse this, they could give non-privileged contributors the option to grant only the 'public_repo' scope.

[Ingo Oeser]

Great decision!

Will there be a pull request based workflow available?

That would lower the barriers even more, since that's what most people are used to. But I am not sure how comfortable you guys with github pull requests these days.

[Steven Hartland]

This is great news but unless you can restrict it to public repos only
we won't be able to authorise this :(

[Anthony Martin]

Carl <carl...@gmail.com> once said:
> Git. Go. Gerrit. Google. Gmail. Github.
>
> Good things come in Gs.

Gangrene. Gastroenteritis. Gonorrhea. Gentrification. Gulag. Git.

Anthony

[Gustavo Niemeyer]

That's superb news. It will finally put an end on my hg-inside-git convolution, done so working on multiple issues at once was more comfortable.

Thanks for going through all the migration bureaucracy.

[tulin...@gmail.com]

What about protecting 'Go' IP? You could still ensure that everything is secure in Perforce with Git Fusion: http://www.perforce.com/git-management-solutions

[Steve Domin]

Fantastic news!

Really nice to see the language evolving with the community that surrounds it and not being dogmatic on that kind of things.

[Aram Hăvărneanu]

Will it be possible to create and comment on issues without a GitHub account?

--
Aram Hăvărneanu

[Aram Hăvărneanu]

On Fri, Nov 14, 2014 at 2:16 PM, Aram Hăvărneanu <ara...@mgk.ro> wrote:
> Will it be possible to create and comment on issues without a GitHub account?

Adding to that. Github, like Google Code, seems to have a concept of
an owner of an issue. I assume that in order to own an issue I have to
have a GitHub username, a plain email would not suffice.

--
Aram Hăvărneanu

[themi...@googlemail.com]

Hi Go guys,

if you would like to also have a lightweight code review tool directly based on GitHub Pull Requests, you can also take a look at http://review.ninja

We use it for our open source projects.

Regards,

Michael

[Rafal Jeczalik]

On 14 November 2014 10:23, Steven Hartland <steven....@multiplay.co.uk> wrote:
>
> This is great news but unless you can restrict it to public repos only we won't be able to authorise this :(

You can always create second account for contributing to Go project. Alternatively you could move your private repositories to separate, private organization - I believe private access permission does not span over all organizations' private repositories.

Question is, if it's worth the effort for you.
 
 

[Russ Cox]

On Fri, Nov 14, 2014 at 4:23 AM, Steven Hartland <steven....@multiplay.co.uk> wrote:

This is great news but unless you can restrict it to public repos only we won't be able to authorise this :(

That's fine. Don't.

The authorization is only so that we can migrate issue tracker issues and comments as you. As it said in the original mail, if you don't authorize that, the GitHub copy of your issues or comments will be posted on GitHub by the gopherbot account instead, but still attributed to you. The only effect of not authorizing the app is that if someone replies to an old issue that you posted, gopherbot will get the reply instead of you.

I did a quick search on golang.org/issue and I found just two issues that you've commented on. If you don't care about seeing replies to them, do nothing at all. If you do care but can't authorize the app, then wait until the migration has happened and then go over to GitHub and click 'watch' on the two issues.

Russ

[Steven Hartland]

We already have the "upstream" repos associated within our organization, but obviously you still need a private fork of said repos to work on them and issue pull requests, which Google would be granted access to with the authorization, so not an option.

Creating a second account would just result account hell, already have a similar mess with my Google accounts which they messed up due to it not supported aliases in gmail, which they still haven't sorted, so not something I'd consider ever again I'm afraid.

[Russ Cox]

On Fri, Nov 14, 2014 at 8:16 AM, Aram Hăvărneanu <ara...@mgk.ro> wrote:

Will it be possible to create and comment on issues without a GitHub account?

No, but GitHub accounts are free, and you can log in using your Google account. I don't even know my GitHub password. As always, if someone doesn't want to set up an account, bug reports via email, whether to the list are privately, are fine.

Since you are one of the active developers, though, I hope you will take the time to set up an account.

Thanks.

Russ

[Russ Cox]

On Fri, Nov 14, 2014 at 8:54 AM, Steven Hartland <steven....@multiplay.co.uk> wrote:

We already have the "upstream" repos associated within our organization, but obviously you still need a private fork of said repos to work on them and issue pull requests, which Google would be granted access to with the authorization, so not an option.

Creating a second account would just result account hell, already have a similar mess with my Google accounts which they messed up due to it not supported aliases in gmail, which they still haven't sorted, so not something I'd consider ever again I'm afraid.

Again, that's fine. Don't grant the access, don't create a second account. Just wait until everything is moved and re-star (sorry, watch) the issues you want updates about.

Russ

[cm...@golang.org]

FYI the builders already run git, for gccgo builds, at least.  I wanted to download the changeset archives through HTTP originally, but it seems mercurial is the only VCS out of bzr, svn, and git that doesn't have that command natively.

On Thursday, November 13, 2014 11:01:50 PM UTC-8, David du Colombier wrote:

While I think moving to Git and Gerrit is a very good
thing, I feel a bit concerned about the builders.

Will the builders be required to run Git? Is there any
plan to modify the builder program to propose alternative
retrieving methods, like downloading the changeset archives
through HTTP?

Thanks.

--
David du Colombier

[David du Colombier]

> FYI the builders already run git, for gccgo builds, at least. I wanted to
> download the changeset archives through HTTP originally, but it seems
> mercurial is the only VCS out of bzr, svn, and git that doesn't have that
> command natively.

My concern was about the Plan 9 builders. Git doesn't run on Plan 9 yet.

We'll have to port Git (as Felipe Bichued, Steven Stallion and Jeff Sickel
ported Python and Mercurial previously), but it will take more than two
weeks.

We don't want to lose the Plan 9 builders just before the big merges
on the 1.5 branch.

To prevent this, we'll probably have to make some changes in our side
on the builder program to be able to checkout changeset archives
from the GitHub website, instead of using Git.

--
David du Colombier

[Brad Fitzpatrick]

I think we could probably use public_repo.  We were using "repo" during testing on private repos.

Andrew, want to re-deploy the cookiemonster GAE app with that change?

[Russ Cox]

On Fri, Nov 14, 2014 at 5:11 AM, <tulin...@gmail.com> wrote:

What about protecting 'Go' IP? You could still ensure that everything is secure in Perforce with Git Fusion: http://www.perforce.com/git-management-solutions

Code review and submits will happen via a Google-hosted instance of Gerrit (see announcement for link). Gerrit is a code review site but also a Git storage server. That Git server will be the master copy of the Go repository. As changes are made there they will be pushed to GitHub automatically. Changes will not flow in reverse, from GitHub back to Gerrit.

To head off the next obvious question, at the start we will not be accepting changes via GitHub pull request. Our focus is on getting something like our current workflow up and running using Gerrit. Once that is done, an obvious next step would be to import GitHub pull requests automatically into Gerrit for review. But we have to get everything else working well first.

Russ

[Russ Cox]

Everything is subject to change, but at least today the plan is to do the merges before moving, in large part to avoid making them depend on nothing breaking in the move. So the Plan 9 builders will be around to test them. I would strongly encourage you to spend time making Git run instead of changing the builders.

Russ

[jerzyg...@gmail.com]

I don't get that hype for migrating everything to Github. Google Code supports Git, so what is the rationale of moving to a third-party service when Google Code is internal and has an excellent issue tracker?

[ron minnich]

On Fri Nov 14 2014 at 9:05:54 AM <jerzyg...@gmail.com> wrote:

I don't get that hype for migrating everything to Github. 

I suggest you give them the benefit of the doubt on this one. 

ron 

[Peter Collingbourne]

Will the gofrontend repository also be moving to GitHub?

On Fri, Nov 14, 2014 at 12:45 AM, Rob Pike <r...@golang.org> wrote:

Go contributors,

When Go became an open source project 5 years ago, Mercurial was the best choice for us for a number of reasons, most important being the ability to support our choice of code review system.

Mercurial has served us well, but it's time to move on. The world today is quite different from the world then. Most members of the Go community use Git and host their work on GitHub, and we should join them. Thanks to the efforts of open source projects like Android, we now have access to a Git-based code review system that fits our workflow.

We are therefore pleased to announce that we plan to migrate the Go project and its subrepositories to GitHub. The issue tracker and the wiki will also be moved; all data will be preserved. We will use a Google-hosted instance of Gerrit for code reviews.

The transition will happen soon after the 1.4 release in early December. All development for 1.5 will happen in GitHub; the Mercurial tree will be closed to changes after the 1.4 release.

We are still developing the plan and will explain more about the transition in the coming weeks.

There is one thing we need to do beforehand, which is to gather the permissions necessary to migrate the issues on the issue tracker. If you have added issues or comments to the Go issue tracker, please visit go-issue-migrator.appspot.com and click on the "Yes, let's do this" button and authorize our migrator application on GitHub. This gives us access to your GitHub account to enable us to re-create your issues and comments as you, so that you will be notified of changes to issues you've contributed to. (It's OK to not give us this permission; if you don't, your issues and comments will be owned by a "gopherbot" account but will still be attributed to you.) We only need your credentials for the transition; once it's done we'll throw them away and—to be sure—you may revoke the token yourself.

As always, our thanks to the community for all the work you do to make Go succeed.

Rob

P.S. For those keeping score, this will be Go version control system number four. Go development started in Subversion, moved to Perforce, then Mercurial, and soon to Git.

[Ian Taylor]

On Fri, Nov 14, 2014 at 10:13 AM, 'Peter Collingbourne' via golang-dev
<golan...@googlegroups.com> wrote:
> Will the gofrontend repository also be moving to GitHub?

Yes, I expect so. It seems best to keep them in sync.

Ian

[Juan Francisco Cantero Hurtado]

On 11/14/2014 09:08 AM, Aram Hăvărneanu wrote:
> I am happy with this change, although it will mean we will have to
> port git to Plan 9. Presumably we can hack the Plan 9 builders to get
> the source somehow, but we still want to be able to do development on
> Plan 9, so we need some sort of git on Plan 9.
>

There is a pure-python alternative to git: https://hg-git.github.io/ .
Probably this is the simplest temporal workaround for your problem.

[Aaron Greenlee]

I think the hype is just that GitHub is so familiar. It won the market share for git services long ago.

Aaron Greenlee

[Nathan Youngman]

That explains it. "public_repo" permission would be much appreciated.

Nathan.

[jeff....@gmail.com]

It doesn't look like getting a Plan 9 build of Git will be that difficult, though we'll have to throw away bits from git/t tree if you don't run lnfs.  Decoding the git/Makefile is... painful, but possibly less so than updating Plan 9's Python + hg to support hggit.

Then again, after seeing the cartoon ad for GitHub Enterprise, all I can think of is Monty Python's "Brave Sir Robbin Ran Away".

Jeff

[Andrew Gerrand]

We've now switched to using the "public_repo" scope and re-deployed the go-issue-migrator app. Try it now.

[Wael M. Nasreddine]

Confirmed! Thanks.

Wael

[Nathan Youngman]

Worked perfectly. Thanks Andrew.

[Han-Wen Nienhuys]

On Sun, Nov 16, 2014 at 9:13 PM, <jeff....@gmail.com> wrote:
>>> My concern was about the Plan 9 builders. Git doesn't run on Plan 9 yet.
>>>
>>> We'll have to port Git (as Felipe Bichued, Steven Stallion and Jeff
>>> Sickel
>>> ported Python and Mercurial previously), but it will take more than two
>>> weeks.

> It doesn't look like getting a Plan 9 build of Git will be that difficult,
> though we'll have to throw away bits from git/t tree if you don't run lnfs.
> Decoding the git/Makefile is... painful, but possibly less so than updating
> Plan 9's Python + hg to support hggit.

You may want to consider looking at porting libgit2 instead, and
writing a command-line client on top of that that implements just what
you need. The libgit2 code is much cleaner and better structured than
cgit.

--
Han-Wen Nienhuys
Google Munich
han...@google.com

[minux]

On Mon, Nov 17, 2014 at 4:20 AM, 'Han-Wen Nienhuys' via golang-dev
<golan...@googlegroups.com> wrote:
> You may want to consider looking at porting libgit2 instead, and
> writing a command-line client on top of that that implements just what
> you need. The libgit2 code is much cleaner and better structured than
> cgit.

Also consider the fact that libgit2 is written using C89 constructs only,
so perhaps we can use Russ' c2go to convert it to Go and then we can
have a pure Go git command. This will surely benefit not only Plan 9
community, but also the whole Go community as well (esp. considering
that we can integrate the code review tool into the Go-based git command
-- no more wrappers or plugins).

[Lucio De Re]

Plus one! (on faith.)

Lucio.

[Dobrosław Żybort]

There is also https://github.com/gogits/git

[Russ Cox]

Please don't.

The last thing I want is to maintain our own code review tools again. One of the best things about moving to Gerrit is that the whole infrastructure is better supported and more robust than Rietveld.

Russ

[Lucio De Re]

Oh, you of little faith! The point of Go is to build tools that can
be relied upon. If you don't trust the tools, who will?

It is a complex political issue and the solution isn't always the
shortest distance between two points. In five years we ought to be
asking ourselves how we coped with the prehistoric tools we had
available.

My personal opinion is that we need to keep refining anything that is
of great service, lest it spring some ugly surprise. One of the tools
that enables us to do this is the introduction of a new, richer
development environment.

Lucio.

PS: With Gerrit you seem to gain resources at the expense of control.
I'm sure there are two or more camps on this issue - and it's not
just bikeshedding.

[gi...@iki.fi]

I'm a nobody, but I propose that the Go team should focus it's limitless
energy to building a stable operating system on which to build a stable
source code management system on which to build, you know, the Go
language. Because it's unknown where the current tools will be headed to
in the years ahead of us. Or, I dunno, not fight the tools unless really
necessary?

(I have no sense of humour.)

[Lucio De Re]

The Go team should only be the "arbiter elegantiarum" for the infinite
offerings from the Go community, of tools and foundations on which the
Go language is expected to thrive. Even that would involve enormous
resources and, in practice, only limited benefits.

But it would have significant historical value, one day.

Lucio.

[james.re...@gmail.com]

WAY TO GO! (pun intended)

[Sharang Dashputre]

Good move!

[Jimmy Zelinskie]

It appears as though the move to GitHub has taken (is taking) place. How long until the Gerrit instance is online or is it already?

[Sebastien Douche]

On Mon, Dec 8, 2014 at 9:45 PM, Jimmy Zelinskie
<jimmyze...@gmail.com> wrote:
> It appears as though the move to GitHub has taken (is taking) place. How
> long until the Gerrit instance is online or is it already?

https://go-review.googlesource.com/



--
Sebastien Douche <sdo...@gmail.com>
Twitter: @sdouche / G+: +sdouche

[max.no...@gmail.com]

I opened an issue on Github, but as suggested by Ian I'll post it here instead, for the original issue see https://github.com/golang/go/issues/9292. He also did mention that this will have to wait for a while, and I'm in no rush. With that being said I wanted to post this while I still remember, so here it goes (again):

Instead of using labels, consider using milestones on Github. They are more or less the same, but come with a nice UI for displaying progress. They can also be tied to releases, by which I mean Githubs download/binaries support. After skimming through the labels I see two potential categories of candidates. First is the go*, e.g. go1.2.0, and second is the release-* labels. The main benefit for doing this is to allow easy overview of what is happening and how much is left till the next release. I also believe this can be automated fairly easily.

Max

[Nathan Youngman]

Worth considering milestones -- I think.

The milestone interface also has due dates, such as a March 1 or June 1st deadline for Go 1.5. The UI looks like this:

https://github.com/gratipay/gratipay.com/milestones

I'm not sure if it's worth the effort to move past releases into milestones, but it would clean up the number of labels listed here:

https://github.com/golang/go/labels

P.S. Code Triage is a handy tool to email you an issue per day to look into (or more, if you like).

http://www.codetriage.com/golang/go

P.P.S. For a Kanban-style view on GitHub issues, Waffle is free for open source. Each column in the board is a label on GitHub. https://waffle.io/

--
You received this message because you are subscribed to a topic in the Google Groups "golang-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-dev/sckirqOWepg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Nathan Youngman
Email: n...@nathany.com
Web: http://www.nathany.com

[Dave Cheney]

I'd like to try using milestones. If it works out for 1.5, I'm happy to do the grunt work to relabel the older issues and milestones.

You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

[Brad Fitzpatrick]

It would mean we could kill one more dashboard:

https://go-dev.appspot.com/#all is already replaced by https://go-review.googlesource.com/#/q/status:open

and it'd be nice if milestones meant we could also kill:

http://research.swtch.com/dashboard/Go1.4#all

It shouldn't be grunt work, though. Github has an API.

[Nathan Youngman]

Milestones may not completely replace the Go open issues dashboard. 

They can be used as a filter, so for example:

https://github.com/go-fsnotify/fsnotify/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22v2+Internals%22

If the labels are pared back so those in the key stand out nicely, it's pretty close. Labels can also be filtered (suggested, documentation, XL)

Would "Go 1.5 + Maybe" be a Maybe label or a milestone or a combination of both? I'm not sure.

What's missing is the lovely graph. It certainly can be done, and there's probably something out there that's pretty close:

http://issuestats.com/github/golang/go

https://waffle.io/golang/go/metrics/throughput (if it ever loads)

Even if the graph is custom generated, dropping it in the readme could be a way to avoid another complete dashboard at a separate url.

The waffle graph looks like this: https://github.com/waffleio/waffle.io#graphs

Nathan.