Switching to Tarmac

[John Arbash Meinel]

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

...
>> a) Go to the Launchpad merge proposal page, mark the whole
>> proposal Approved. Make sure there is a "Commit Message" set
>> (rather than just a description)
> 
> Should we just copy the entire description to the commit message? 
> That would seem like a sensible default to me - I very much like
> having the whole description and link to the code review in the
> main commit log.

It is a sensible default, and I think 'rv-submit' does just that.

Sometimes I write Descriptions that are actually discussions about the
patch which aren't appropriate for a commit message, (like saying
'Looking for feedback about XYZ'). However, many fit just fine.


> If I've got one branch that is dependent on several others, is
> there a way to make sure that it is merged after them, or do I have
> to manually wait until the previous branches have landed?

I know that Tarmac will not land things that have prerequisites that
have not landed yet.

I *think* there was a bug that if you mark 5 branches all in a row as
Approved, it might get to the last one, see it has an unlanded
prerequisite, and put it back to Needs Review rather than just putting
it later in its work queue.

So the answer is:
a) Tarmac will safely not land things that have prerequisites
b) It might need a little bit of TLC to get all branches in a series
landed.


> 
>> 4) We will remove running the juju-core test suite as a
>> prerequisite for landing lp:goose changes. (We still don't have
>> dependency tracking, so landing code in a dependency can break
>> landing code in juju-core, but we still need some way to land a
>> patch and land the patch that fixes juju-core.)
>> 
>> 5) Right now the 'test' in Tarmac is: go fmt ./... && go build
>> ./... && go test ./...
> 
> To save a few seconds, I'd suggest that it should be "go install
> ./..." rather than "go build ./...".

I'm a little concerned about previous test failures poisoning GOPATH.
Do you know the heuristic go uses to determine if a library needs
rebuilding? If it is only timestamps, I would be hesitant to trust it
too much. (Though the plan is to move to clean builds eventually anyway.)

> 
>> Which means that it doesn't yet automatically update
>> dependencies. I'm looking to change it to something that builds a
>> pristine GOPATH every time (using a shared repository to avoid
>> having to actually download the code each time).
>> 
>> Along the way, I'm hoping we can get dependency tracking, so that
>> it doesn't build from TIP of everything each time.
>> 
>> 6) When we get Continuous Integration (from a Jenkins instance),
>> I'll want to add a job that grabs TIP of everything so we know
>> what it will take to keep things on HEAD. (eg, we can be told
>> that the last change to goose/mgo/go.crypto will break juju-core,
>> so we can prepare a patch etc.)
>> 

...

>> 
>> 8) When we get things like GOMAXPROCS=2 and the test suite
>> working reliably, I will be happy to set that in the bot so that
>> we can ratchet up our baseline. Flaky tests (things that fail
>> once in a while) will be pretty ruthlessly disabled. I never want
>> us to feel like you should just resubmit without modifications to
>> get code to land.
> 
> What's the plan with respect to live tests? I'd love to have some 
> assurance that things still work on the various possible 
> providers.

That is also part of (6) Continuous Integration. So breaking the live
tests shouldn't block landing of code (because we don't want to wait
2h for every submission), but we should know about it right away so we
can fix it.

Also, my understanding is that Live tests are more prone to flakiness
(because they depend on an external system). So again, it fits well
with "run them asynchronously" rather than "blocking trunk".

> 
>> 9) I will add people's SSH keys to go-bot's account, so that we
>> have a workaround when the bot is being rude/broken/etc.
> 
> my ssh public key:
> 
> ssh-rsa
> AAAAB3NzaC1yc2EAAAADAQABAAABAQDOjaOjVRHchF2RFCKQdgBqrIA5nOoqSprLK47l2th5I675jw+QYMIihXQaITss3hjrh3+5ITyBO41PS5rHLNGtlYUHX78p9CHNZsJqHl/z1Ub1tuMe+/5SY2MkDYzgfPtQtVsLasAIiht/5g78AMMXH3HeCKb9V9cP6/lPPq6mCMvg8TDLrPp/P2vlyukAsJYUvVgoaPDUBpedHbkMj07pDJqe4D7c0yEJ8hQo/6nS+3bh9Q1NvmVNsB1pbtk3RKONIiTAXYcjclmOljxxJnl1O50F5sOIi38vyl7Q63f6a3bXMvJEf1lnPNJKAxspIfEu8gRasny3FEsbHfrxEwVj
>
> 
rog at rog-x220
> 
> cheers, rog.
> 

I've already got you. I added everyone I could think of that had
available Launchpad SSH keys:
 https://launchpad.net/~go-bot/+sshkeys

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlG4MO8ACgkQJdeBCYSNAAOYXwCeOlggfLi705DC217EdmpEeqrJ
angAoLUMQlTus1L0y1CAbUu4kHJTlBaK
=QM3B
-----END PGP SIGNATURE-----