Heads up: migrating juju-core to github

[Ian Booth]

Hi all

We now have all the pieces in place to migrate juju-core to Github.

PROPOSAL: migration is scheduled to occur at 10:00 UTC Thursday 29 May.

Once the migration commences, no further landings to juju-core on Launchpad will
be possible. It is expected that juju-core will be open to accept new landings
on Github by EOD on the 29th.

BEFORE:

Before the migration commences, you should try to have as much in progress work
as possible finalised and landed on trunk on Launchpad. If you have work that is
not yet landed, we will provide simple commands that can be run to export your
work from bzr and then create a new git branch.

Most impacted will be the CI guys who also package the Juju releases. Curtis,
will you be able to accommodate the timing of this change?

AFTER:

After the migration, any scripts you have that consume juju-core branches off
Launchpad will need to be altered to pull from Github instead. This applies
particularly to the CI scripts.
Obviously you will need to update your development environments also; IDE
plugins etc

LANDING PROCESS:

The workflow is based on what the GUI guys use for juju-gui (they migrated some
months ago). So it is tried and tested.

As is the case now with our tarmac instance, a landing bot will run unit tests
against "trunk" and only merge the pull request if the tests pass. The landing
bot will be run as a Jenkins job. Emails will be sent on success and failure.

DOCUMENTATION:

In the next day, we will publish a hacking document that describes the workflow
and procedures used to land branches in the New World Order. Because of
differences between bzr and git, creating a pull request for Github will
necessarily involve manual developer input to perform a degree of rebasing.
Sadly, this is unavoidable and is a consequence of using git.

1.18 AND OLDER RELEASES

These will continue to be hosted on Launchpad and not be migrated to Github.

FOLLOW UP WORK:

Once juju-core is migrated, we will over time also migrate other juju
dependencies like goose, gwacl, gomassapi etc. We will also split out re-usable
chunks of code like juju's cmd infrastructure etc.

WHAT YOU NEED TO DO:

Please consider how this change impacts your work and if you have any objections
to the proposed cutover timeframe, raise these NOW. We will delay the cutover if
required.

Read the hacking document when it is published tomorrow and raise any concerns
also. We won't necessarily be able to accommodate too much bikeshedding on the
workflow; it's based on proven process and we can tweak things as required after
the cutover if necessary.

Thanks,
Tanzanite Squad