a simple git branching model
This is a very simple git workflow. It (and variants) is in use by many people. I settled on it after using it very effectively at Athena. GitHub does something similar; Zach Holman mentioned it in this talk.
|Export your symbols using EXPORT_GPL_SYMBOL or EXPORT_SYMBOL as normal.|
|Build your provider module as always - take a look at the Module.symvers file as we're going to depend on what it exports.|
|Your dependent module will now need a Makefile that uses KBUILD_EXTRA_SYMBOLS in order to reference these additional symbols|
|obj-m += dependent.o|
|KDIR := /lib/modules/$(shell uname -r)/build|
|PWD := $(shell pwd)|
Be as available as possible This is probably the best piece of advice I received from a friend prior to starting my new job. Things move quickly back at the home office, and since you’re not there, there’s a built-in delay for someone wishing to communicate with you.
If it always takes hours for someone to get your ear for just a minute, you’ll build a reputation as someone who’s “never around”–even if only subconsciously–among your coworkers.
As a remote employee, you have to work harder at being available to avoid the impression that you’re never available.
Strive to build a reputation as someone who is quick to respond. Be eager to hear the latest developments on projects so that you’re never out of sync with everyone else in your office.
We use the golang-migrate tool (formerly known as mattes/migrate) - build it with postgres support.
$ go get -v -u -tags 'postgres' github.com/golang-migrate/migrate/cli $ migrate -h Usage: migrate OPTIONS COMMAND [arg...]