More failing tests...

[William Reade]

On Sun, 2013-03-03 at 14:31 +0400, John Arbash Meinel wrote:
> Technically the goose-bot has a configuration for both goose and
> juju-core. And when we land changes for goose, it runs the juju-core
> test suite, which should mean juju-core's test suite is running
> cleanly on the bot.
> 
> At the moment, it is pointed at lp:~goose-bot/juju-core/trunk
> 
> Some thoughts:
> 
> 0) It isn't hard, it is just a matter of sorting out all the specific
> polices we want to use.

I'd prefer to have something imperfect right now: it'd still be better
than what we have. Policies can be fixed if we get them wrong, but the
current situation is clearly unworkable.

> 1) It is a little weird to manage 'juju-core' with something named
> 'goose-bot', but I didn't have a better name at the time. We could
> just rename it to 'gopher-bot'.

I don't see any engineering or business value in changing the name...
but if you really want to, I'm not going to stop you.

> 2) We would want to change where 'lp:juju-core' points, which will
> cause people using older bzr to re-update their trees. (Not hard, just
> something you ran into when we moved 'lp:goose'.) New bzr records
> "bazaar.launchpad.net/+branch/{goose,juju-core}" but older ones
> resolved that URL to the ~gophers/juju-core/trunk (which would then
> change.)

This is a matter of 2 lines of instructions in an announcement email,
right?

> We could alternatively give goose-bot the ability commit directly to
> gophers, but I'd like to avoid that.

As you wish; I'm not so clear on the implicit tradeoffs here and I'm
happy to defer to you.

> 3) Because of the dependency ordering, we do have at outlet to allow
> people to push to trunk directly, but it isn't something that is easy
> to do.

An outlet is certainly good to have, but it doesn't have to be too easy
to reach for.

> 4) Tarmac support is a little messy right now because lbox uses the
> Description as the commit message while Tarmac uses Launchpad's
> "Commit Message" field. So you have to copy & paste the description
> into the commit message, and then mark the message Approved.

Can anyone estimate the time/hassle cost of adding "lbox submit
--tarmac"? This feels like the biggest problem to me, and it sounds as
though it should be reasonably simple to resolve... but I also don't
think it should prevent us from moving on this.

> 5) Removing direct access to trunk will make it hard to get
> dependencies updated without us getting to the point where we do some
> sort of versioning. I get the feeling goose is getting pretty close to
> ready for v1, though.

Unless it's actually fossilized, it doesn't matter how stable goose is.

The package-versioning model espoused by go is, I am now convinced,
straight-up crack: it's predicated on the assumption that repeatable
builds don't matter (or maybe that everybody will cut a new version for
every change to every package, which doesn't seem to be happening).

> We could also look at merging dependencies into juju-core, but I'm
> really not a big fan of that. We really should design things as
> re-usable libraries, and merging into 1 large tree tends to pollute
> that. (You can do it, but there is always the tendency to make a patch
> inside the juju-core tree, and then it is hard to pull that back out
> to a separate library.)

I don't think the two goals are in opposition. Our dependencies should
of course, where possible, be developed independently as re-usable
libraries. However, we should be able to run repeatable builds. The go
tools are currently too naive to accommodate our needs without cloning
our deps into the tree; and tarmac will, I think, reduce the costs of
the cloning to acceptable levels.

Once we have dependencies cloned in-tree, I think it's perfectly
reasonable to state that patches made inside the tree (rather than
cloned from upstream) are completely unacceptable (it's not like you can
do so accidentally -- conscious volition is always involved). Maybe, one
day, we'll need to fork some dependency, but that is not a decision that
should be taken in isolation without discussion or documentation: until
then, dependencies must only be cloned.

John and Dave, as the expert and the volunteer respectively: can I leave
this in your hands please?

Cheers
William


> John
> =:->