Any and all contributions are welcome. These are just some notes on areas where I know work is necessary and I haven’t gotten there myself. Some are probably larger chunks of work than others. Some have open issues describing the need or bug, others don’t. For those that don’t, it might be a good idea to open an issue on GitHub to announce that you’re working on it and to collect any relevant discussion.
Vet the protocol spec. This is the single most important artefact in the project and it’s essential that it makes sense and is unambiguous. More eyes are always welcome.
Take a look at the open enhancement issues – grab one and start hacking! While you’re at it, the open bugs are also free for the taking!
Head over to Transifex and help translate syncthing into your native language.
I’m using the intellij go plugin, I can’t figure out how to debug, do I need a special gdb version? my stock gdb with ubuntu doesn’t seem to see any go debug symbols or show the source.
I found that I have to remove “-w” on the ldflags in build.sh
Go’s threading model is entirely alien to gdb, and will get gdb very very confused a lot of the time. Stepping over functions will often do something different from what you expect. I don’t use it myself, preferring old school printf style debugging…
Did you take a look at http://golang.org/doc/gdb? I can see how a debugger is nice when exploring a new code base, but when debugging I find it’s usually enough to understand what a given data structure looks like at some point in the code, and besides the bug is probably not happening on my own system anyway but somewhere else out there - hence the STTRACE stuff.
As for why Go and not Java or Scala, first of all I think Go is a much much nicer language, and Syncthing in Python?.
Here are some: