Go contribution workshop in Russia

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 that 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 purpose of which is to study the internals of Go and send their 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 some 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 to 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 a 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 Grakhovac created the #kfu-go-2018 channel in 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. This 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).

Lesson # 1

In fact, it turned out that the list of tasks included those that were interests or were clear to me personally. This was realized during the compilation of the list, but it is difficult to influence it.

Perhaps it would be better if this list were made up of several people with differing profiles and interests.

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.bat for Windows) with various errors.

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

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

Lesson # 2

Separately, it is worth mentioning that Delius Farhulin helped me. Empirically revealed that more than four people alone are very difficult to carry. The situation is getting complicated when none of the participants, except mentors, knows Go. It is necessary to perform many additional steps. However, if there were four of us, it would be much easier (there were 15 students).

The first patches in the project Go

For the second lesson, there was a goal to go directly to the counterbuting:

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 gerrit in the work without the risk of something to break.
Prepared stickers for presentation to those who successfully put patches into Go.

We were lucky: the scratch repository was broken. Someone sent the incorrect code to the repository and because of this trybots (CI tests) always failed. One of the tasks I prepared was to fix 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).

Lesson # 3

For good "on time" stickers, you need to contact trusted suppliers. Saving on the nearest points where they can print stickers without cutting is not a good idea. And you can not combine the logo of a gopher with something else: a gopher with an Intel tablet in his hands violates all imaginable laws of stickers.

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 was sent a few patches.

Then came code freeze and the course came to a logical end. At this point, 17 patches were injected. 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 tasks of minimal size and not requiring a large context. Here various linters helped. Run " gometalinter --enable-all " on the package from GOROOT and 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 types of tasks).

In theory, a good second-level task is to improve the tests in Go: increasing coverage, adding or refining 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:

encoding / json: add unmarshalTypeError ( #22369 )
time: optimize time.Time.Sub and time.Since ( #17858 )
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.

Lesson №4

Most of all it is worth paying attention to this particular part, the inevitable deepening and the questions that follow it. I doubt that there are people who know all parts of Go to be able to support any choice, so here everything again converges to the lack of different experts.

Workshop v2

Some of the problems described above would be solved in 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 is not necessary to come to such hackathons in order to start contributing to Go, a motivating example could be 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.