Ubuntu Wiki

   1 [17:00] <dholbach> Next up is the incredible and unstoppable Colin Watson, talking to us about "Doing merges right!"
   2 [17:00]  * cjwatson fusses around a bit looking for his notes. :-)
   3 [17:00] <cjwatson> Hi, I'm Colin Watson, from the Ubuntu Foundations team, and this talk is called "Doing Merges Right".
   4 [17:00] <cjwatson> You can ask questions at any time in #ubuntu-classroom-chat.  Please write QUESTION at the beginning of your question so I can see it more easily.  I'll stop at the end of a section and answer some questions.
   5 [17:01] <cjwatson> This session is mostly for people who've never done merges before and want to know how to do it properly, though it will help if you know what a patch looks like.
   6 [17:01] <cjwatson> If you already know how to do merges, though, consider listening in anyway.  I'm going to describe up-to-date tools that not everyone will already be familiar with, and I'll cover a few common mistakes along the way.
   7 [17:01] <cjwatson> Apologies to the desktop folks, but this is unashamedly a terminal-based session.  It is not full of sexy slides and whizzy graphics, because I don't do those.  Love The Terminal.  The Terminal Is Your Friend.
   8 [17:01] <cjwatson> To follow along with this talk, you should install the bzr, bzr-builddeb, and ubuntu-dev-tools packages.  Make sure that bzr is version 2.0 or better; karmic's is fine.
   9 [17:01] <cjwatson> WHY
  10 [17:01] <cjwatson> Every time we open a new development release of Ubuntu, we need to merge our changes with those made in Debian.
  11 [17:02] <cjwatson> Not everyone finds this exciting, but it's really important; it keeps our repository up to date with the rest of the free software world, and it gives us an opportunity to audit the changes we're carrying and discard ones that don't make sense any more.
  12 [17:02] <cjwatson> Since we have a lot of packages and a relatively small number of developers, it's important that we have some common understanding of how to go about this.
  13 [17:02] <cjwatson> Plus, half the time you end up merging something you haven't worked on for months if at all, so some basic habits come in handy ...
  14 [17:02] <cjwatson> In this session, I'm going to run through an example merge using a couple of different methods.
  15 [17:02] <cjwatson> WHEN
  16 [17:02] <cjwatson> http://merges.ubuntu.com/ is your friend for finding things to do.  The lists are divided into a section for packages that haven't been uploaded so far this release, and a section for packages that have been touched but still have a newer version in Debian.  The first section is usually more important.
  17 [17:02] <cjwatson> Each merge has a "last uploader" recorded alongside it.
  18 [17:03] <cjwatson> The last person who uploaded the package is the default assignee for each merge.  We sometimes call this the "touched it last" method - you touched it last, it's yours!
  19 [17:03] <cjwatson> You must always contact the last uploader before doing a merge; please don't just run down the list and submit lots of merges for sponsorship.
  20 [17:03] <cjwatson> This is a convention to try to avoid duplicate work.  You may also often find that the assignee for a merge has a reason for not just going ahead and merging (perhaps some other package needs to be adjusted), so always talk to them first.
  21 [17:03] <cjwatson> That said, people often welcome help with their merge workload as long as they're told about it, so don't be shy about asking.
  22 [17:03] <cjwatson> We expect all packages to have been merged at least once by Debian Import Freeze (see https://wiki.ubuntu.com/ReleaseSchedule) and after that point we don't actively try to keep the merge lists short.
  23 [17:04] <cjwatson> After Feature Freeze, you have to have a good reason for doing a merge, not just "it was on the list", so expect to be asked searching questions by your sponsor if they can't see why you bothered. :-)
  24 [17:04] <cjwatson> HOW
  25 [17:04] <cjwatson> I'm going to go through the same example in two different ways.  Firstly, I'm going to use Bazaar, the revision control system used for (among other things) a good deal of Ubuntu development.  Secondly, I'm going to do things the old-fashioned way.
  26 [17:04] <cjwatson> Bazaar is really much better at dealing with merges, since that's one of the core functions of a revision control system!  For the example here, it doesn't make so much difference, but it gets more obvious with more complicated packages.
  27 [17:04] <cjwatson> The Bazaar workflow isn't so extensively covered in MOTU documentation, so I'm going to spend a bit more time on it.
  28 [17:04] <cjwatson> However, we're still in the process of rolling this out for all packages, and it doesn't quite all work yet.  Sometimes you need to fall back to the old-school method to get your work done.
  29 [17:05] <cjwatson> Don't worry too much about having to do this; the automatic imports will catch up even if you do your work outside Bazaar.
  30 [17:05] <cjwatson> But first:
  31 [17:05] <cjwatson> THE TAO OF MERGING
  32 [17:05] <cjwatson> 1. Keep Ubuntu changes as small as possible.  If Debian fixes the same bug in a different way, use their fix and discard ours unless it's clearly better in some way.
  33 [17:05] <cjwatson> 2. Send changes upstream or to Debian whenever possible.  We don't really want to maintain big divergent patches in Ubuntu if we can avoid it; unless things are truly Ubuntu-specific, it's always better to pass them up so that the rest of the free software world can use our improvements too.  You can use the 'submittodebian' script to help with this.
  34 [17:05] <cjwatson> 3. Sync with Debian whenever possible.  When following these directions, if you find that there are no Ubuntu changes left, then stop!  Request that the package be synced instead: https://wiki.ubuntu.com/SyncRequestProcess
  35 [17:05] <cjwatson> 4. Write good changelogs that explain what changes we're still carrying in Ubuntu.  This makes it easy to look at a package and quickly see how the Ubuntu version differs.
  36 [17:06] <cjwatson> Any questions before I dive into our first example?
  37 [17:06] <cjwatson> Shout if I'm going too fast.
  38 [17:07] <cjwatson> 17:06 <randomaction> QUESTION: what do background colours in MoM mean?
  39 [17:07] <cjwatson> It's odd that this isn't documented anywhere ...
  40 [17:07] <cjwatson> (at least as far as I can see)
  41 [17:07] <cjwatson> Anyway, the colours refer to the Priority field of the package.
  42 [17:08] <cjwatson> Red is required, sort of orange/yellow is important, light green is standard, mid-green is optional, dark green is extra.
  43 [17:08] <cjwatson> This is just a heuristic to try to sort more important packages to the top of the list.
  44 [17:08] <cjwatson> It doesn't refer to the importance of the *merge*, which can't be determined automatically, but it helps.
  45 [17:09] <cjwatson> (I think I might have the precise colour/priority mapping a little wrong, but you get the idea!)
  46 [17:09] <cjwatson> OK, I'll carry on.
  47 [17:09] <cjwatson> BAZAAR
  48 [17:09] <cjwatson> I'm going to use a simple merge that's currently outstanding as an example: ipmitool.
  49 [17:09] <cjwatson> Look at https://merges.ubuntu.com/universe.html and (if it hasn't been merged yet by the time you read this) you'll see ipmitool there, with Chuck Short's name against it as the last uploader.
  50 [17:09] <cjwatson> Normally, you can access current branches for Ubuntu and Debian packages at lp:ubuntu/SOURCE or lp:debian/SOURCE respectively, where SOURCE is the source package name.
  51 [17:10] <cjwatson> (You can use 'bzr lp-open' to look at these in a web browser, too.)
  52 [17:10] <cjwatson> These are special aliases that expand to five-level names; for instance, lp:ubuntu/ipmitool is currently lp:~ubuntu-branches/ubuntu/lucid/gnu-fdisk/lucid.  This breaks down as (owner, distribution, release, source package, branch name).
  53 [17:11] <cjwatson> err, s/gnu-fdisk/ipmitool/ obviously!  Sorry, error in my prep ...
  54 [17:11] <cjwatson> Debian branches currently expand to .../debian/squeeze/..., since for the Lucid development cycle we're merging from Debian testing, not unstable.  This may change in future.  To get branches corresponding to unstable, use lp:debian/sid/SOURCE.
  55 [17:11] <cjwatson> In order that the transcript of this talk will continue to be useful for some time to come, I've taken copies of the current state of the Ubuntu and Debian branches for ipmitool, and pushed them to Launchpad, using my own Launchpad username as the owner.  Anyone can push whatever they like this way, as long as it meets the Launchpad terms of use.
  56 === l is now known as Guest68800
  57 [17:11] <cjwatson>   lp:~cjwatson/ubuntu/lucid/ipmitool/udw
  58 [17:11] <cjwatson>   lp:~cjwatson/debian/squeeze/ipmitool/udw
  59 [17:11] <cjwatson> BAZAAR: STARTING THE MERGE
  60 [17:11] <cjwatson> Let's prepare to do our example merge.
  61 [17:11] <cjwatson> Make a new directory and cd into it.  Type 'bzr init-repo .', which should respond with a few lines starting "Shared repository with trees (format: 2a)".  This is optional, but it means that any branches we create under here will share common storage for their revisions, which saves you both disk space and network bandwidth when you have several branches with shared history.
  62 [17:12] <cjwatson> Fetch the branches we want to merge like this:
  63 [17:12] <cjwatson>   bzr get -r7 lp:~cjwatson/ubuntu/lucid/ipmitool/udw ubuntu
  64 [17:12] <cjwatson>   bzr get lp:~cjwatson/debian/squeeze/ipmitool/udw debian
  65 [17:12] <cjwatson> (Normally, of course, this would be lp:ubuntu/ipmitool etc., and we pick a specific revision of the Ubuntu branch here because the next revision has the results of the merge.)
  66 [17:13] <cjwatson> If you've used Bazaar before, you may be reaching for 'bzr merge' about now.  bzr-builddeb provides a 'bzr merge-package' command, which we're going to use instead.  I'll explain the difference later on.
  67 [17:13] <cjwatson> Let's try merging the Debian changes into the Ubuntu branch.  Bazaar will automatically start from wherever the two branches you're working on diverged; you don't need to tell it "merge from 1.8.11-1 up to 1.8.11-2".
  68 [17:13] <cjwatson>   <cjwatson@sarantium ~/src/ubuntu/ipmitool/udw/ubuntu>$ bzr merge-package ../debian
  69 [17:13] <cjwatson>   Text conflict in debian/changelog
  70 [17:13] <cjwatson>   Text conflict in debian/control
  71 [17:13] <cjwatson>   Text conflict in debian/patches/series
  72 [17:13] <cjwatson>   3 conflicts encountered.
  73 [17:13] <cjwatson>   The merge resulted in 3 conflicts. Please resolve these and commit the changes with "bzr commit".
  74 [17:13] <cjwatson> BAZAAR: CONFLICTS
  75 [17:14] <cjwatson> That was easy, wasn't it?  Shame about the conflicts.  Type 'bzr status' and you'll see what this has left in your working tree.  Incidentally, you can get detailed help on any Bazaar command using 'bzr help COMMAND'.
  76 [17:14] <cjwatson> (I'll pause for a bit here to let anyone following along catch up with the commands)
  77 [17:15] <cjwatson> 17:15 <SevenMachines> i'm getting 'bzr get lp:~cjwatson/debian/squeeze/ipmitool/udw debian
  78 [17:15] <cjwatson> 17:15 <SevenMachines> sorry, bzr: ERROR: unknown command "merge-package"
  79 [17:15] <cjwatson> SevenMachines: You need to install the 'bzr-builddeb' package.
  80 [17:15] <cjwatson> 17:01 <@cjwatson> To follow along with this talk, you should install the bzr, bzr-builddeb, and ubuntu-dev-tools packages.  Make sure that bzr is version 2.0 or better; karmic's is fine.
  81 [17:18] <cjwatson> presentation syndrome here, just fixing up the branch :-)
  82 [17:20] <cjwatson> I've fixed the broken example Ubuntu branch now, so try again if you had trouble earlier.
  83 [17:21] <cjwatson> so, carrying on ...
  84 [17:21] <cjwatson> Looking at 'bzr status', this has changed four files, only one of which was entirely without incident (the new file debian/patches/passwd_option).  Let's look at each of the three conflicts.  I normally do debian/changelog last, since it's the summary of everything else I've done.
  85 [17:21] <cjwatson> In each file with a conflict, you'll see "<<<<<<<", "=======", and ">>>>>>>" markers.  These are placed each time Bazaar finds a part of the file that's changed on both sides of the merge.
  86 [17:21] <cjwatson> The section between "<<<<<<<" and "=======" shows that part of the file in the current branch, and the section between "=======" and ">>>>>>>" shows that part of the file in the branch you're merging from.
  87 [17:21] <cjwatson> You're expected to remove the markers once you've resolved the conflict.
  88 [17:21] <cjwatson> Edit debian/control and you'll see markers around Maintainer and Build-Depends lines.  Bazaar has left some files around that you can use to figure out what the change from the base revision on each side was:
  89 [17:22] <cjwatson>   diff -u debian/control.BASE debian/control.THIS
  90 [17:22] <cjwatson>   diff -u debian/control.BASE debian/control.OTHER
  91 [17:22] <cjwatson> So in fact just the Maintainer lines changed on the Ubuntu side, and only the Build-Depends line changed on the Debian side.  We can safely take the XSBC-Original-Maintainer and Maintainer lines from our side and the Build-Depends line from the Ubuntu side.  Bazaar errs on the side of caution when changes are very close together in a file like this.
  92 [17:23] <cjwatson> Save this and move on to debian/patches/series.  Here we have a real conflict: one line was added on the Ubuntu side, and a different line on the Debian side.
  93 [17:23] <cjwatson> However, if we look at the patch files in debian/patches/ that these lines are referring to, we can see that they touch totally different files and do completely different things, so we should just keep both.
  94 [17:24] <cjwatson> (In my sample merge, I did this by moving the Ubuntu patch below the Debian one, so that all the Ubuntu work was "on top" at the end.  In this case it isn't really important though.)
  95 [17:24] <cjwatson> Now for debian/changelog.  This will get more automatic in future, but for now you usually just get a big conflict with the Ubuntu changelog on one side and the Debian changelog on the other.  Edit this so that the changelog entries come in version order (1.8.11-1ubuntu1 is less than 1.8.11-2, so it should come further down the file.
  96 [17:25] <cjwatson> Now that we've gone through all the files, we can tell Bazaar that we've done so.  Type 'bzr resolve'.  (You normally don't need to tell it which files you've resolved; it will look at all the conflicted files and see if any conflict markers are still there.)  In this case it says "All conflicts resolved" and we can be happy; otherwise we might need to go back for another look.
  97 [17:25] <cjwatson> CHANGELOG
  98 [17:25] <cjwatson> We're done now, right?  Er, not quite.  We still need to write a changelog entry for our merge.  You can use 'dch -i' to create a skeleton one.
  99 [17:25] <cjwatson> The style of this new changelog entry is important.  It should describe all the important changes that are still present in Ubuntu after merging from Debian.
 100 [17:25] <cjwatson> You don't need to list details that are intrinsic to it being an Ubuntu upload; don't clutter up changelogs with comments about Maintainer field changes, for instance.
 101 [17:26] <cjwatson> You don't necessarily need to list any changes that you've dropped (if they've been merged into Debian, say) unless there's something particularly interesting about this.
 102 [17:26] <cjwatson> Normally, you should try to focus on the *functional* changes ("Add widget creation ability") rather than painstakingly listing every file that's changed.  The revision control system can tell people about the latter if they really care.
 103 [17:26] <cjwatson> If the previous merge changelog entry matches whatever your personal standards of clarity are, then you can just copy and paste it.  In this case (with due respect to the previous merger, who seemed to have a complicated job on his hands!), I chose to write my own:
 104 [17:26] <cjwatson>   ipmitool (1.8.11-2ubuntu1) UNRELEASED; urgency=low
 105 [17:26] <cjwatson>     * Merge from Debian testing.  Remaining changes:
 106 [17:26] <cjwatson>       - Add Dell-specific commands.
 107 [17:26] <cjwatson>    -- Colin Watson <cjwatson@ubuntu.com>  Fri, 29 Jan 2010 12:59:16 +0000
 108 [17:27] <cjwatson> (there were some more blank lines in there, lost in the process of pasting into IRC; fill them in mentally)
 109 [17:27] <cjwatson> If there are any merge bugs in Launchpad, remember to close them here, using the "(LP: #NNNNNN)" syntax.
 110 [17:27] <cjwatson> BAZAAR: FINISHING OFF
 111 [17:27] <cjwatson> Have a look at your changes to make sure they're sensible.  'bzr status' shows a summary.  'bzr diff' shows the detailed patch you're about to commit, relative to what's currently in Ubuntu.  You might also want to check the resulting Ubuntu changes relative to what's in Debian; for that, use 'bzr diff --old ../debian'.
 112 [17:28] <cjwatson> Of course there's lots more stuff you can do here - you can use the full power of the revision control system.  See online documentation for more.
 113 [17:28] <cjwatson> All is well, so we can commit.  The changelog says UNRELEASED, so this is marked as a work in progress, but we might as well record what we've done.
 114 [17:28] <cjwatson>   bzr commit -m 'merge from Debian 1.8.11-2'
 115 [17:28] <cjwatson> Bazaar won't let you commit if there are still unresolved conflicts, which is a great protection against accidents.
 116 [17:29] <cjwatson> Note that Bazaar doesn't commit merges automatically if they succeed; you still have the opportunity to look over them and make sure you're happy before actually changing your branch.
 117 [17:29] <cjwatson> Let's now try building our package.  Install the build-dependencies if you need to, and then type 'bzr bd' (short for builddeb).  (This is like debuild, and in fact you can use debuild if you're careful and know what you're doing, but 'bzr bd' is a bit smarter about some details of Bazaar branches.)
 118 [17:29] <cjwatson> Have a look at the top of the output.  You'll notice that we never downloaded ipmitool_1.8.11.orig.tar.gz, but it finds it anyway because James Westby is a GENIUS.
 119 [17:29] <cjwatson> Actually, the automatic package imports store enough data in each branch to be able to reconstruct the original source tarball.  They use 'pristine-tar' for this, which is quite space-efficient.
 120 [17:30] <cjwatson> 'bzr merge-package', and its relatives, 'bzr import-dsc' and 'bzr merge-upstream', take care of details like this, which is why it's worth using them rather than plain 'bzr merge'.
 121 [17:30] <cjwatson> (They also make sure that there's something in the history representing each upstream release.  If you want the details, look at 'bzr log -n0'.)
 122 [17:30] <cjwatson> Now, as it happens, my package fails to build due to some horrible disagreement between autoconf and libtool.  But dealing with autotools problems is a subject for another talk!
 123 [17:30] <cjwatson> If you need to fix something like this, you can do so in a separate commit from the main merge; that way people can easily see the new changes you've made in the history.  Make sure to document any new changes like this in debian/changelog.
 124 [17:31] <cjwatson> Let's pretend it all worked, and I want to build a package for upload to Ubuntu (or perhaps to a PPA).
 125 [17:31] <cjwatson> Run 'dch -r' to finalise the changelog, and 'bzr bd -S -- -v1.8.11-1ubuntu1' to build a source package.
 126 [17:31] <cjwatson> The '-v1.8.11-1ubuntu1' bit says that you want all the changelog entries since 1.8.11-1ubuntu1 to end up in the .changes file.  This means that people following along with the lucid-changes mailing list will get complete information about what changed, rather than just the relatively uninformative merge changelog entry.
 127 [17:32] <cjwatson> If there's a new upstream version not already in Ubuntu, you'll need the -sa option as well to upload the .orig.tar.gz.
 128 [17:32] <cjwatson> Assuming this works, you can look at the result in the parent directory.  I'd recommend using 'debdiff' to compare your source package both to the last version in Ubuntu and to the version in Debian that you're merging.  You don't need to be too obsessive about this, but a quick debdiff check has caught a lot of basic errors in the past.
 129 [17:32] <cjwatson> 17:32 <sebner> cjwatson: [QUESTION]: What was the repo-init thing for at the beginning?
 130 [17:33] <cjwatson> 'bzr init-repo .' sets up a shared repository.  This means that, instead of having to store all the revisions for the Ubuntu branch and all the revisions for the Debian branch separately, you can store them in the common repository since actually several of them are just the exact same revisions.
 131 [17:34] <cjwatson> It also means that you don't have to download those revisions twice, which saves a couple of megabytes.  If your connection to the Internet is anything like mine, you might value this!
 132 [17:34] <cjwatson> (carrying on)
 133 [17:34] <cjwatson> If it all works, then 'debcommit -r' (this commits and tags), and upload!
 134 [17:34] <cjwatson> You can push stuff to personal branches on Launchpad for review using 'bzr push lp:~YOURUSERNAME/ubuntu/lucid/SOURCE/BRANCH-NAME', and set up a merge proposal.
 135 [17:35] <cjwatson> Using the merge proposal, you can generate debdiffs for bug reports in case your sponsor prefers that.
 136 [17:36] <cjwatson> I have more links on this sort of stuff for further reading at the end, but any questions on the Bazaar section of this session before I carry on?
 137 [17:36] <cjwatson> 17:36 <sebner> [QUESTION]: How can I haXX0r bzr to work like git when using bzr log. (It does the same horrible thing as svn, showing the first revisions instead of the recent ones and backscrolling is not always possible)
 138 [17:36] <cjwatson> sebner: I'm not sure I understand your first problem, as bzr log shows the most recent revisions first
 139 [17:36] <cjwatson> as does git log
 140 [17:37] <cjwatson> but you can do 'bzr log --forward' if you want to change that
 141 [17:37] <cjwatson> if you want a pager, | less :-)
 142 [17:37] <cjwatson> It's often helpful to use 'bzr log -n0', which shows all merged revisions as well.
 143 [17:42] <cjwatson> also 'bzr alias' is a generally useful thing to know about, for when you want to change a command's default options, or even add a new command that's more to your liking.
 144 [17:42] <cjwatson> 17:42 <geser> I usually do "bzr ci" and "bzr mark-uploaded" instead of "debcommit". Should I switch to debcommit or doesn't it matter?
 145 [17:43] <cjwatson> geser: debcommit saves you from having to type commit messages again in many cases.  Aside from that, right now in practice they're equivalent.
 146 [17:44] <cjwatson> If you work with lots of different revision control systems, debcommit acts as a partial abstraction layer, which I find moderately useful.  But it's mainly avoiding having to type the same thing into the changelog and the commit log editor that I find useful.
 147 [17:45] <cjwatson> 17:43 <sebner> [QUESTION]: How many % of the archive is already usable with such branches and actually being used currently
 148 [17:46] <cjwatson> I don't have a percentage figure (maybe jml does, or james_w if he's watching?), but coverage has got to the point where if you're comfortable with the workflow it's worth trying.
 149 [17:46] <cjwatson> http://package-import.ubuntu.com/failures/ has a log of current import failures.
 150 [17:47] <cjwatson> (which is a bit longer than I remember, I wonder if there's some systemic problem right now)
 151 [17:47] <jml> cjwatson, Last time james_w told me it was in the high 90s.
 152 [17:47] <cjwatson> the main thing people are likely to run into is that it doesn't handle some cases of dpkg v3 source packages right now.  I expect this will be fixed pretty soon.
 153 [17:47] <cjwatson> Anyway, I'd better move on now as I have 13 minutes left.
 154 [17:47] <cjwatson> OLD-SCHOOL
 155 [17:47] <cjwatson> It turns out that it's kind of hard to import lots of versions of 15000-odd packages from two different distributions and get all the bits lined up properly.  Who'd have thought?
 156 [17:47] <cjwatson> Eventually this will settle down, but for now you'll still need to do things by hand every now and then.
 157 [17:48] <cjwatson> merges.ubuntu.com can help with this.  https://merges.ubuntu.com/i/ipmitool/REPORT shows the results of an automatic merge, and you'll see that there were a few conflicts, basically just what we went through above.
 158 [17:48] <cjwatson> You can use 'grab-merge ipmitool' to get all the files.  This gives you an 'ipmitool' directory with lots of files in it, including an 'ipmitool-1.8.11-2ubuntu1' subdirectory with the best that merge-o-matic could manage.
 159 [17:48] <cjwatson> As before, you should go through and resolve the conflicts.  There's no equivalent to 'bzr resolve', though also no protection against accidentally leaving conflicts around; you have to keep track of this yourself.
 160 [17:48] <cjwatson> merge-o-matic has merged the changelogs for you, but you still need to write a changelog entry, as before.  Make sure to change the changelog trailer line to your name and e-mail address rather than "Ubuntu Merge-o-Matic <mom@ubuntu.com>", or risk embarrassment!
 161 [17:48] <cjwatson> Type '../merge-buildpackage' when you're done.  This is like the 'bzr bd -S' bit above.  Then unpack the source package somewhere and check that it builds.
 162 [17:49] <cjwatson> Please use debdiff to make sure your changes against both Debian and Ubuntu make sense.  This is much more important when you aren't using Bazaar, because you can't use 'bzr diff' to check each individual change you're making, and it's possible to leave conflicts in by mistake.
 163 [17:49] <cjwatson> To get a sponsor to look at this, you'll need to generate debdiffs against both Debian and Ubuntu, attach them to a merge bug, and subscribe either ubuntu-main-sponsors or ubuntu-universe-sponsors as appropriate.  There's more detail on this in the MOTU wiki area.
 164 [17:50] <cjwatson> And remember: if you're actually going to ask for sponsorship for this merge, you should still check with the previous uploader, even though I used it as an example for this session!
 165 [17:50] <cjwatson> FURTHER READING
 166 [17:50] <cjwatson> For more details on merge proposals, see https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging, and https://wiki.ubuntu.com/DistributedDevelopment/Documentation for general docs on using Bazaar for Ubuntu packaging.
 167 [17:50] <cjwatson> For general advice on merging (particularly "old-school"), see https://wiki.ubuntu.com/UbuntuDevelopment/Merging, which has more detail than I could fit into this session.
 168 [17:50] <cjwatson> FUTURE
 169 [17:50] <cjwatson> Ultimately, we want to get to the point where every upstream has a Bazaar import, every Debian package has a Bazaar branch matched up with that import, and every Ubuntu package has a Bazaar branch matched up with both of those.
 170 [17:50] <cjwatson> The closer we get to this, the easier it will be to merge code between upstream, Debian, and Ubuntu.  We have this for a few select packages already: I handle grub2 and openssh this way and it's lovely.
 171 [17:51] <cjwatson> If you want to help get us there for more packages, please join https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel.
 172 [17:51] <cjwatson> Thank you for following along, and happy merging!
 173 [17:51] <cjwatson> Any questions?
 174 [17:51] <cjwatson> 17:51 <sebner> [QUESTION]: Are there any consequences when using bzr to work on a package, then another(?) developer merges some new versions/revisions by hand and then you decide to merge the newest version again with bzr?
 175 [17:51] <cjwatson> The automatic import script is reasonably clever (although it could be improved).
 176 [17:52] <cjwatson> If it tries to import and finds that there are more revisions beyond the last thing it did, it imports, but moves the "conflicting" revisions aside and files a bug on the 'udd' project about them.
 177 [17:52] <cjwatson> The main thing that's lacking from this right now is good notification to the people responsible for those changes.
 178 [17:52] <cjwatson> But at least nothing is lost.
 179 [17:53] <cjwatson> If you make changes in bzr and *do* upload them, then as long as you tag your upload the automatic importer will take that as evidence that that's a good representation of that version.
 180 [17:54] <cjwatson> So if I uploaded 1.8.11-2ubuntu1 from the ipmitool example above and pushed my changes to lp:ubuntu/ipmitool, and then somebody else uploaded 1.8.11-2ubuntu2 without using bzr, that would all work fine - the automatic import would work on top of my changes.
 181 [17:54] <cjwatson> 17:51 <vocx> QUESTION: With all the tools that exist today. Is it significantly easier to merge and patch Debian packages? I have a feeling that aspiring maintainers may be overwhelmed by the multitude of "bzr action" commands, along with the traditional "dpkg" tools.
 182 [17:55] <cjwatson> So, there's always a learning curve, and it's certainly a bit difficult in a transitional period when you have to learn two sets of tools.
 183 [17:55] <cjwatson> However, hardly any serious upstream project works without revision control.
 184 [17:55] <cjwatson> So I think it's quite justifiable to try to move Ubuntu to having consistent revision control - in fact I think the end result will be much less confusing.
 185 [17:56] <cjwatson> My experience is that once you've acquired basic familiarity with the relevant revision control tools, merging and patches is much, much less time-consuming, and the error rate is much lower.
 186 [17:57] <cjwatson> I also hope that ultimately it will be easier to build ways to encourage aspiring developers this way.  When you get right down to it, having to send repeated versions of debdiffs around isn't all *that* great either ...
 187 [17:59] <cjwatson> Thanks again.  If you have other questions, feel free to ask me directly or on #ubuntu-devel or #ubuntu-motu.