Trunk must never be broken

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

To start with, we fully agree that trunk should always be passing.
We've certainly followed that in all other projects that we've worked on.

However, in other projects, we've also had more infrastructure for
helping us with it. Mostly around recognizing that human beings are
fallible, and helping us cope with that.

Some things that I feel are missing to make it easier:

1) A bot like PQM/Tarmac/Jenkins that will run trunk tests in an
isolated environment.

Especially because of GOPATH's limitations, it is pretty hard to keep
an isolated 'trunk' directory where you can just update a dependency
and make sure everything keeps working.

In this particular case it was environment variables, but that is also
something that a bot-running-trunk makes very easy to get right, but
is hard for a human to get right.

2) Something like 'versions.cfg' that allow you to specify what
version of dependencies you actually need.

Without this, you run into the hard problem that you need to update an
API (say adding a parameter), but you also need to update the callers.
You can try to land them roughly in sync, but they'll never be exactly
at the same time. And even worse, if you ever have to rollback things,
then you have to figure out what else needs to get rolled back in the
dependencies, because you haven't recorded what the actual
dependencies are.

Is there something in go? The only thing I've seen is that 'go get'
looks for a branch/tag named 'go1'. But that seems to be more about go
language compatibility (which isn't as big of an issue since go1).

I realize that we can sort-of workaround it for now. But it would be
nice if we knew that we could get back to any old snapshot of
juju-core trunk and have the tests pass. Without mapping to specific
dependency versions, that's not really practical.

3) Also, given dependency issues, what is the general process for
running juju-core tests? "go get -u launchpad.net/juju-core && go test
./..." ? Because essentially to land anything into goose, we now need
to run the juju core tests, because other people will always run goose
trunk, even if we haven't managed to update juju-core yet.


4) It is possible we can't do the technical work to do these. So maybe
just a checklist of "things to make sure you have covered" before
landing code?

John
=:->

On 2012-12-07 20:53, Gustavo Niemeyer wrote:
> Folks,
> 
> We've had an issue today where the tests committed onto the
> openstack provider were broken for multiple reasons: it needed
> specific variables in the environment on normal runs, and an
> expected error didn't match what the library reported.
> 
> A temporary hack was committed to avoid the problem before the real
> fix comes:
> 
> https://codereview.appspot.com/6912047
> 
> Let's please be careful to avoid introducing this kind of issue in
> the future, since everybody's work is blocked on broken trunks.
> Special attention in this case is needed on the API of the goose
> package as well.. when doing API changes, these should be
> coordinate so that the change is merge both in juju-core's trunk
> and in goose itself about the same time, so that people can update
> the dependency immediately and keep going.
> 
> Back at Conectiva we had a rule where people would have to buy
> cookies to everybody whenever trunk was broken. It's unfortunate we
> can't do that at Canonical. :-)
> 
> 
> gustavo @ http://niemeyer.net
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Cygwin)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDFlPkACgkQJdeBCYSNAAPrjQCfYqFsJ9n+HodRELhVvBC3czsh
48cAoLWrxbha+Gn6Pep+k7/ZOPPIeY0U
=7xsm
-----END PGP SIGNATURE-----