Demo: bzr
Author: James Westby
Running time: 19:10
Format: OGV

Hi. This video is designed to show some of the ways in which using bzr
packaging can make things easier and more efficient. It's not designed
to show everything and it's certainly not documentation. That will come
later. And some of the things I'm going to show you aren't decided yet,
aren't finalized yet, or won't be available in the first iteration;
however, it should give you an idea of where we want to go and some of
the things that you'll be able to do.

So I have here a bunch of the lvm2 package. Which I have actually
done work in bzr on, although I submitted things as debdiffs at the
end, so it didn't require anyone else to use bzr to review my work or
anything. But I was able to test things out and see how doing the work
in bzr could be made easier.

So you can see I made a change here. This was in Hardy and I had merge
the package into Intrepid, which I then did in bzr. We have a whole
report of the history and you can see all the uploads I made as separate
revisions in bzr.

If we use the bzr-viz command from bzr-gtk we can see all the revisions
in a more graphical way with little notes and little arrows where things
join up. Down the left we have all the uploads to Ubuntu and then merged
in at various points are uploads to Debian and then merged into that are
the other points are the actual upstream code. So upstream released
version 2.0.2.26 which was merged which  was uploaded by Debian with
their packaging changes here and that was merged into Ubuntu.

Time Code: 2:19
You can see the diff of any particular revision by double clicking and
select any part of it. This is just using the wonderful bzr-gtz to
explore various things. You can, for instance, go from this revision and
see it all in context so you get to my changelog entry along with a very
small change that I made to the package.

Time Code: 2:50
In the first iteration you are going to have the Ubuntu uploads and
upstream Debian will be visible here. It's something we're going to add
in later, it's quite a bit more work to make sure we get it right for
every package. So even though it works ok on this one and we're going to
try things out and make sure it's rock solid before we deploy it. So you
won't have the benefit of being able to see the diff to Debian, but
that's something that can come later.

Time Code: 3:24 (screen change back to the terminal)
Seeing all the changes, seeing the history, is one thing that you are
able to do. One other very useful thing is the annotate operation.
bzr-gtk again provides an excellent interface to do this in the bzr
gannotate command.
        $ bzr gannotate debian/rules

Time Code: 3:43
So if we annotate the debian/rules file what you can see is...Each line
of the file which is coloured so shows that it's been changed. Most of
it comes from this revision of Debian, which is actually the first
revision we have because don't have that much deb history of this
package. So you can see most of it is that colour, but these ones,
various lines that are coloured differently.

Time Code: 4:25
So if we, say for instance, take these, then we can click a line and see
the log message which was put in at the same time for these uploads are
just taken from the Debian change log. We can jump straight from this if
we double click then we are able to see the full diff of that revision.
If we are interested in what happened to do with this change then we can
see the diff. Which means we can see the change and we can jump to the
change log entry and we can see what else was changed in the same
revision. This is very useful when you're merging and especially when
you're merging other people's work and you may have a change and you're
not sure what change in the changelog it refers to. This can help narrow
it down.

Time Code: 5:26
It's rather coarse grained at the moment because it just is full uploads
because that's the history we have. If people start using bzr this will
be become more fine grained and you would be able to see more precisely
what the changes were that were associated.

Time Code: 5:40
The other thing you are able to do in bzr gannotate is jump backwards in
time. So if we select a line we're interested in and we choose the back
button it would jump back and show you the state of the file just before
that change. It isn't that interesting here, but it can be very useful.
This is great for examining history if you are investigating a bug or
something and you are interested in the history of the package and when
a line was changed and things like that this can be very useful for
tracking down bugs and things like that.

Time Code: 6:25
These are a couple of tools we get instantly available by having things
available in bzr. This is a lot easier than dealing with tar packages
because you have it all in one place. You don't need to pull down
multiple source packages and start diffing them to find these things
out. And an annotate operation is very very difficult to do without a
version control system.

Time Code: 6:48 (back to terminal)
So as well as the history, or using the history, bzr is very good at
merging. Once we have Debian available in bzr as well you'll be able to
do merge from Debian when they make an upload by just simply:
        $ bzr merge ../debian
I have the branch on disk, but you could give a remote path and these
paths will be standardized so we'll be able to provide wrappers, which
could be something like:
        $ bzr merge-debian
and it would know what to do.

Time Code: 7:30
If we just bzr merge ../debian it merges in all the changes that Debian
made in that time and it resolves them where possible automatically by
looking the changes we made in that time and the changes they made in
that time. Where it is not able to resolve them automatically it leaves
a text conflict. These are indicated by arrows in the file, just like
this. This means we changed the file to look like this part. And Debian
changed the file to look like this part. So there was a conflict there.
We both made a change in the same area.

Time Code: 8:25
We would need to investigate and decide which one was better, which one
we wanted and fix that up. We're also able to get help with this. I have
a plug-in installed, bzr-xmerge. I could run that on the file. Which
will bring up the three versions of the file in meld, a graphical merge
tool. On the left we have the original file, which is the ancestor which
is what both versions are based off of. In the middle we have our
version and on the far side is Debian's version. So you can see that we
made various changes here and Debian made changes like these additions
here. We can decide what we want, what we don't want. We might want
those and we might want those and those. And once we're done we can save
that and the file will be how we want it.

Time Code: 9:30
This is just the great tool meld. It's very useful for doing these
things, but it's very easy for bzr to provide the information that meld
needs. But it is not as easy for mergematic or similar. It's integrated
so it's very easy to fire it up. As well as the tools like that you
still have the history available and you're still able to use the
annotate operation in order to find out information that may be useful
to you. It can often make things easier.

10:18
Once you've made all the changes you need, resolved all the conflicts,
then you'll be able to test build the source. And once you're happy with
it you can commit your changes and upload them as you like or ask for
sponsorship. I won't finish that off, I'll just revert those changes
because I want to show what happens if we want to integrate a new
upstream version before Debian decides to.

10:55
If we would like to do this, there is a command called bzr
merge-upstream which is designed to do exactly that. So we run:
        $ bzr merge-upstream
and we can pass it the URI of the upstream tarball. LVM2 is released on
RedHat's FTP server so we log in with an  anonymous login,
sources.redhat.com name of the tarball. I'm using this out of my shell
history so I don't have to remember the URL or look it up.

11:36
We also provide it with the distribution we would like to upload to. It
would be nice not to have to do this and there may be ways to do it. But
at the moment it's simpler to ask the user to provide it, this is partly
because I don't want to assume the user is developing for Ubuntu. They
might be preparing an upload to Debian to sync into Ubuntu. This allows
us to not assume that, but it require an extra step for the user. But as
I said, hopefully we'll get rid of it in the future.

12:15
And the last thing before I do it is the version we'd like this to be.
So we just say it's going to be 2.02.39, which corresponds to the
upstream release and you don't need to provide the deb revision again
this could be guessed from the name of the tarball, but that's quite
risky, and here for instance but here it could go wrong because that
looks like a version number, but that's the version number we want. That
again could be something that isn't needed in the future so it could be
as simple as bzr merge-upstream, name of upstream tarball;

13:00
however, you also have watch files (which are part of the upstream
tarball) so merge-upstread could be asked to use those. So it could be
as simple as bzr merge-upstream which then uses the watch file to find
the tarball and then guesses the version number, works out what
distribution you want and does everything you want. However we have to
provide those three bits of information at the moment.

13:30
Let's run the command. Um, ah yes. This is just a small bug that needs
to be worked out. I'll just remove the old file from when I did a
practise run, and try again. So what that's currently doing is
downloading the tarball from the remote site that's why it's taking a
few seconds to sort that out over FTP. It's got it now.

14:00
It's now committed the upstream tarball as a new revision on the
upstream branch which it makes as needed. And here it has merged it into
a packaging branch. This again can cause conflicts. Say for instance
this was a direct edit of source, it wasn't using a patch system and
upstream has integrated our changes. If they had integrated our changes
exactly, if we'd cherry picked from upstream exactly, then it wouldn't
be a conflict; however there's been some difference in what we did and
what they did.

14:40
So if we open the file we again find conflict markers. We can see that
we had two lines, and they have also added in this ps3disc line which we
didn't add. So they've done some more than what we cherry picked. We're
happy with what they've added, because they've done a superset of our
changes. So we'll just drop what we did. Done. So you'd continue on for
the other conflicts.

15:06
And then run dch. (This could be made automatic.) So just run dch to
update the change log. And assuming we'd resolved all the other
conflicts we'd now be ready to do a test build and upload or ask for
sponsorship of that change. Now when you asking for sponsorship you
don't need to worry about finding the old source package and running deb
diff. You can simply use bzr to extract the diff you need.

16:00
If we just look at the old version number. Then we can just run
        $ bzr diff -r package:<package>
And that is spitting out the diff from the current Ubuntu version so
including all the upstream changes.

16:28
This again could be wrapped so you don't need to do the package: bit.
That just means we can do something like tag, we've hooked into bzr and
chosen package. It could be wrapped so you don't need that. What I'd
like to do is have package Ubuntu and use the last version that was
uploaded to Ubuntu. The difficulty is in working out what the "last"
version was, what they intended. But that's something that we'd like for
the future so it would be really easy to prepare a new upstream version
because you'd follow those previous diffs(?) and just run that or even a
wrap for that and then ask for sponsorship of that diff or push your
changes and ask for the changes to be pulled and built and uploaded.

17:25
So that gives an overview of some of the things that you're able to do
in bzr, hopefully it shows some of the features that will be easier in
the future and also gives you some ideas of where we could go beyond
that. Tools could be built on top of bzr quite easily using its rich API
in order to do things like test merge a new upstream version when the
watch file identifies that there is a new one. Obviously these tools
could be built at the moment but hopefully they become easier to build
and there will be less reinvention have to be done for each one because
they're all able to make use the version control system underneath to
make these things easier.

18:10
These are the sorts of things that will come further down the line and
we can discuss what sort of tools you'd like, and how you'd like them to
work. The current focus is on making the packages available in bzr and
then once we have that we can start thinking of ideas of what to do with
it. It's going to take us a while to make all of the packages available.
They will be available in the next couple of months. Once we've tried
that out, find all the bugs, then we're going to actually integrate the
Debian information as well. That means you'll able to bzr-merge from
debian, which I demonstrated, which won't be available in the first
instance.

I hope that's given you some ideas, if you'd like to get involved and
start making this a reality then please get in touch. Thank you very much.