Long planned to send a patch to Go, but constantly postponed? Faced with difficulties, did not know where to start? In this article I will describe how we conducted the Go contribution workshop in Kazan, its results, as well as the lessons the organizers have learned.

Spoiler: it is planned to repeat this event when Go enters the phase of active development (goes out of the code freeze state). See the details under the cut.

What is Go contribution workshop?

Around the world, from time to time, various programmers gather Go meetings, the goal of which is to study the internals of Go and send its changes to it. It all started with GopherCon .

Someone comes to help others deal with the workflow, pick up the problem and solve it, then go through the review and, ideally, get to the patch infusion in the upstream . Others come in as the "First Time Contributor".

If you are interested in one of the following, you might be interested in participating:

• Immerse yourself in the low-level details of the Go toolchain (compiler, linker, assembler, ...)
• Speed ​​up a function from the standard library or runtime
• Add missing examples or tests for any of the packages.
• Refactor some very scary code
• Refine support for a rarer architecture or OS (you have hardware and / or OS)
• Talk with those who have been contributing to Go for a long time.

The list is not complete, everyone can find something in it.

Workshop in Russia

At some point I decided that I wanted to have a hand in organizing such an event. Most of all I wanted to be in the circle of people with similar interests.

The preliminary program of carrying out turned out approximately for 6-10 hours (the range of the best and worst case). The most suitable format looked like a hackathon, but at that time it was not possible to find sponsors. But there was an opportunity to conduct optional classes for the Scientific and Practical Platform of IVMiIT KFU , once a week for one and a half hours. The obvious drawback: due to the large intervals between participation, would have to spend some extra time. And no pizza. Sigh

Quite unexpectedly, I was a guest in the GolangShow podcast (ep. 119) , where I let out about the idea of doing something similar for students. A little later, Elena Grahovac created a channel #kfu-go-2018in the Russian-speaking Go community . Not only KFU students could communicate there, but also all those who were interested to participate remotely.

After that, the university approved the details of the conduct, the specific dates became known. Instead of the hackathon, we got a course on the Go programming language. It did not greatly change the content, the goal remained the same and it was clearly described in the announcement .

This was followed by scanning the tracker in the search for such tasks that could be performed within the framework of the event, at least partially (even better - completely).

Any participant could go to the Go tracker and choose anything for themselves, but for the tasks from the list, explanations were ready, and for some of them a partial solution.

Most of the content that was developed during the course is available in the kfu-go-2018 repository . You can also find tasks.org .

First meeting

Students who have not previously written to Go came. Most of them have not even heard of such a programming language.

We spent half of the first lesson building Go from sources. On different computers, there were different, including unexpected problems. Different operating systems, versions of system compilers (someone did not intend to use Go 1.4), and so on. Tritely did not work ./make.bash( make.batfor Windows) with various errors.

When the majority still had a working Go, our first Hello World was to deduce from the compiler ( go tool compile) the canonical message when the new flag was passed to it.

90 minutes passed: we talked about Go, compared it with C ++, assembled the toolchain, disassembled the bootstrap process and assembled the updated compiler.

The first patches in the project Go

For the second lesson, the goal was to go directly to the counteringuing:

• We agreed with Daniel Martí that he will be available at the agreed time and will be able to conduct a review (put +2 if the patch is trivial and correct).
• Ilya Tokar prompted the scratch repository, where it is much easier to send the first CL (change list). Allows you to try out gerrit at work without the risk of breaking something.
• Prepared stickers for presentation to those who successfully injected patches into Go.

We were lucky: the scratch repository was broken. Someone sent an incorrect code to the repository and because of this trybots (CI tests) always failed. One of the tasks I prepared was to correct what caused the build error.

By the end of the lesson, 6 patches were sent:
CL105415 , CL105395 , CL105356 , CL105416 , CL105355 , CL105375 .

Stickers received each.

It took 180 minutes: they disassembled the Go development process, issued a Google CLA for everyone , set up a gerrit, sent "hello world" patches, fixed the scratch repository assembly, and one of the participants sent the patch to golang / go (the merge was on the same day).

The rest of the classes were held under a more free scheme. We came and worked on our tasks, exchanged experiences and helped each other. Almost every such meeting sent a few patches.

Then came code freeze and the course came to a logical end. At this point, 17 patches were infused . We still get together on Saturdays and work on different Go utilities ...

Difficulties of the “second step”

The easiest thing was to take the first step. For those who work uncertainly with git, the scratch repository is a great solution.

It was not too difficult to find the tasks of the minimum size and not requiring a large context. A variety of linter helped here. Run " gometalinter --enable-all" on the package from GOROOTand choose what to fix.

It was more difficult with the tasks to a higher level. It was difficult for me to suggest this, and it was difficult for them to choose one. At the same time, there was an understanding that we had already outgrown the correction of the linter warnings (i.e. the challenge had disappeared, for productive training it was necessary to look for new kinds of tasks).

In theory, a good second-level task is to improve tests in Go: increasing coverage, adding or improving benchmarks, correcting incompletely correct or disabled tests, checking regression tests, and so on. This requires some immersion in the test package, but the scope of the changes will be minimal and it is easy enough to check the result. But not everyone likes to work with tests.

Examples of what we managed to undertake as level 2 tasks:

1. encoding / json: add field in UnmarshalTypeError ( #22369)
2. time: optimize time.Time.Sub and time.Since ( #17858)
3. cmd / compile: avoid slow versions of LEA instructions on x86 ( #21735)

They started them closer to the code freeze, so they did not have time to finish: 2 Saturdays remained for 90 minutes, but this is not enough. Moreover, each worked on his task. Perhaps it would be easier if you split into teams of at least two people, for example, in the case of issue21735 , you can simultaneously test different hypotheses and study different parts of the compiler in parallel, then share knowledge.

Workshop v2

Some of the problems described above would be solved by an alternative format, when a more complex task would not require its solution for three weeks. The next workshop should be held in the form of a continuous event, at least for 4-5 hours, and ideally with a break and for longer.

Usually, the hackathon format also implies some preparation of participants before the start, namely the choice of the task and the preliminary description of the ways to solve it, the formation of teams. This can also help increase the number of successful contributions.

We need more mentors who can help participants in real time to select and solve problems.

The choice of a city depends on the number of participants and their geographic distribution. Four options are closest to me: Moscow, Innopolis, Kazan, Nizhny Novgorod.

Finally

It’s not necessary to come to such hackathons to start contributing to Go, a motivating example is Marco’s article As a Newcomer to Go Contributing . However, in the company of the same interested people it is easier to overcome the initial discomfort and confusion, to go all the way from beginning to end.

If you are not indifferent to this topic, stay tuned, look in on golang-ru.slack . The next period of active development of Go begins from August 2018 : not too far away to forget about it, and not too close not to have time to get ready.

Bonus materials for beginning contributors

• Presentation How to contribute to Go to Stanislav Afanasyev ( goandfix.me )
• Slides How to Contribute to Go
• Slides Golang compiler internals for ARM64
• Relatively recently, new readme began to appear, targeting new contributors: cmd / compile , cmd / compile / internal / ssa .

Upcoming events

• June 20: The London Go Contributor Workshop
• 1-3 August: GopherCon UK , which will also be Contributor Workshop