Merge lp:~jr/ubuntu-packaging-guide/02-udd-introduction into lp:ubuntu-packaging-guide

Proposed by Jonathan Riddell
Status: Merged
Approved by: Barry Warsaw
Approved revision: 67
Merged at revision: 48
Proposed branch: lp:~jr/ubuntu-packaging-guide/02-udd-introduction
Merge into: lp:ubuntu-packaging-guide
Diff against target: 530 lines (+275/-192)
4 files modified
index.rst (+11/-3)
traditional-packaging.rst (+5/-0)
udd-getting-the-source.rst (+142/-0)
udd-intro.rst (+117/-189)
To merge this branch: bzr merge lp:~jr/ubuntu-packaging-guide/02-udd-introduction
Reviewer Review Type Date Requested Status
Barry Warsaw (community) Approve
Review via email: mp+68078@code.launchpad.net

Description of the change

split out udd-intro into a real introduction to UDD and a separate page for getting the source, also add some honesty about UDD on the front page and stub article for traditional packaging

To post a comment you must log in.
Revision history for this message
Jonathan Riddell (jr) wrote :
64. By Jonathan Riddell

add images

Revision history for this message
Barry Warsaw (barry) wrote :

I guess there's some overlap with your other merge proposal. I can't review the whole thing again. Any chance you can make this branch depend on your other branch so that only the diffs in this branch are visible?

65. By Jonathan Riddell

merge in trunk

66. By Jonathan Riddell

no change commit to refresh merge proposal

Revision history for this message
Jonathan Riddell (jr) wrote :

Updated

67. By Jonathan Riddell

merge in trunk

Revision history for this message
Barry Warsaw (barry) wrote :

Couple of notes:

* There's some very cool stuff in the dev branch of bzr that will make the rmadison checks go away. I've been trying them out and they're fantastic.

* Often, when a package is out of date, instead of using apt-get source, i'll use `bzr import-dsc <url>` where the url is the remote url to the .dsc file. I usually grab those from packages.ubuntu.com. I like this a bit better because, while you cannot merge these import-dsc branches with the udd branch, you still get all the other benefits of version control.

review: Approve
68. By Jonathan Riddell

simplify ensuring the version is up to date for new warnings built into bzr

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== added file 'images/kdetoys-udd-branch.png'
2Binary files images/kdetoys-udd-branch.png 1970-01-01 00:00:00 +0000 and images/kdetoys-udd-branch.png 2011-07-25 09:48:39 +0000 differ
3=== added file 'images/kdetoys-udd-diff.png'
4Binary files images/kdetoys-udd-diff.png 1970-01-01 00:00:00 +0000 and images/kdetoys-udd-diff.png 2011-07-25 09:48:39 +0000 differ
5=== modified file 'index.rst'
6--- index.rst 2011-07-22 15:08:17 +0000
7+++ index.rst 2011-07-25 09:48:39 +0000
8@@ -9,8 +9,14 @@
9 The guide is split up into two sections:
10
11 * A list of articles based on tasks, things you want to get done.
12-* A set of articles that dig deeper into specific bits of our tools
13- and workflows.
14+* A set of knowledge-base articles that dig deeper
15+ into specific bits of our tools and workflows.
16+
17+This guide focuses on the Ubuntu Distributed Development packaging method.
18+This is a new way of packaging which uses Distributed Revision Control
19+branches. It currently has some limitations which mean many teams in Ubuntu
20+use :doc:`traditional packaging</traditional-packaging>` methods. See the
21+:doc:`UDD Introduction</udd-intro>` page for an introduction to the differences.
22
23 Articles
24 --------
25@@ -20,6 +26,7 @@
26
27 introduction-to-ubuntu-development
28 getting-set-up
29+ udd-intro
30 fixing-a-bug
31 fixing-a-bug-security
32
33@@ -31,7 +38,7 @@
34
35 debian-dir-overview
36 testing
37- udd-intro
38+ udd-getting-the-source
39 udd-working
40 udd-sponsorship
41 udd-uploading
42@@ -39,6 +46,7 @@
43 udd-merging
44 udd-patchsys
45 udd-newpackage
46+ traditional-packaging
47
48
49 Indices and tables
50
51=== added file 'traditional-packaging.rst'
52--- traditional-packaging.rst 1970-01-01 00:00:00 +0000
53+++ traditional-packaging.rst 2011-07-25 09:48:39 +0000
54@@ -0,0 +1,5 @@
55+=====================
56+Traditional Packaging
57+=====================
58+
59+FIXME describe traditional packaging here
60
61=== added file 'udd-getting-the-source.rst'
62--- udd-getting-the-source.rst 1970-01-01 00:00:00 +0000
63+++ udd-getting-the-source.rst 2011-07-25 09:48:39 +0000
64@@ -0,0 +1,142 @@
65+==================
66+Getting the Source
67+==================
68+
69+Source package URLs
70+===================
71+
72+Bazaar provides some very nice shortcuts for accessing Launchpad's source
73+branches of packages in both Ubuntu and Debian.
74+
75+To refer to source branches use::
76+
77+ ubuntu:package
78+
79+where *package* refers to the package name you're interested in. This URL
80+refers to the package in the current development version of Ubuntu. To
81+refer to the branch of Tomboy in the development version, you would use::
82+
83+ ubuntu:tomboy
84+
85+To refer to the version of a source package in an older release of Ubuntu,
86+just prefix the package name with the release's code name. E.g. to refer to
87+Tomboy's source package in Maverick_ use::
88+
89+ ubuntu:maverick/tomboy
90+
91+Since they are unique, you can also abbreviate the distro-series name::
92+
93+ ubuntu:m/tomboy
94+
95+You can use a similar scheme to access the source branches in Debian, although
96+there are no shortcuts for the Debian distro-series names. To access the
97+Tomboy branch in the current development series for Debian use:
98+
99+ debianlp:tomboy
100+
101+and to access Tomboy in Debian Lenny_ use::
102+
103+ debianlp:lenny/tomboy
104+
105+
106+.. _`Bazaar`: http://bazaar.canonical.com/en/
107+.. _`Intrepid`: https://wiki.ubuntu.com/IntrepidIbex
108+.. _Maverick: https://wiki.ubuntu.com/MaverickMeerkat
109+.. _Lenny: http://debian.org/releases/stable/
110+
111+
112+Getting the source
113+==================
114+
115+Every source package in Ubuntu has an associated source branch on Launchpad.
116+These source branches are updated automatically by Launchpad, although the
117+process is not currently foolproof.
118+
119+There are a couple of things that we do first in order to make the workflow
120+more efficient later. Once you are used to the process you will learn when it
121+makes sense to skip these steps.
122+
123+
124+.. _branching:
125+
126+Creating a shared repository
127+----------------------------
128+
129+You want to work on the Tomboy package in Natty, and you've verified
130+that the source package is named ``tomboy``. Before actually
131+branching the code for Tomboy, create a shared repository to hold the
132+branches for this package. The shared repository will make future
133+work much more efficient.
134+
135+Do this using the `bzr init-repo` command, passing it the directory name we
136+would like to use::
137+
138+ $ bzr init-repo tomboy
139+
140+You will see that a `tomboy` directory is created in your current working
141+area. Change to this new directory for the rest of your work::
142+
143+ $ cd tomboy
144+
145+
146+Getting the trunk branch
147+------------------------
148+
149+We use the `bzr branch` command to create a local branch of the package.
150+We'll name the target directory `tomboy.dev` just to keep things easy to
151+remember::
152+
153+ $ bzr branch ubuntu:tomboy tomboy.dev
154+
155+The tomboy.dev directory represents the version of Tomboy in the development
156+version of Ubuntu, and you can always ``cd`` into this directory and do a `bzr
157+pull` to get any future updates.
158+
159+.. _up-to-date:
160+
161+Ensuring the version is up to date
162+----------------------------------
163+
164+When you do your ``bzr branch`` you will get a message telling you if the packaging branch is up to date. Occationally the importer fails and packaging branches do not match what is in the archive. A message saying::
165+
166+ Packaging branch status: OUT-OF-DATE
167+
168+Means the importer has failed. You can find out why on
169+http://package-import.ubuntu.com/status/ and `file a bug on the UDD
170+project`_ to get the issue resolved.
171+
172+
173+Getting a branch for a particular release
174+-----------------------------------------
175+
176+When you want to do something like a `stable release update`_ (SRU), or you
177+just want to examine the code in an old release, you'll want to grab the
178+branch corresponding to a particular Ubuntu release. For example, to get the
179+Tomboy package for Maverick do::
180+
181+ $ bzr branch ubuntu:m/tomboy maverick
182+
183+
184+Importing a Debian source package
185+---------------------------------
186+
187+If the package you want to work on is available in Debian but not Ubuntu, it's
188+still easy to import the code to a local bzr branch for development. Let's
189+say you want to import the `newpackage` source package. We'll start by
190+creating a shared repository as normal, but we also have to create a working
191+tree to which the source package will be imported (remember to cd out of the
192+`tomboy` directory created above)::
193+
194+ $ bzr init-repo newpackage
195+ $ cd newpackage
196+ $ bzr init debian
197+ $ cd debian
198+ $ bzr import-dsc http://ftp.de.debian.org/debian/pool/main/n/newpackage/newpackage_1.0-1.dsc
199+
200+As you can see, we just need to provide the remote location of the dsc file,
201+and Bazaar will do the rest. You've now got a Bazaar source branch.
202+
203+
204+.. _`status of the package importer`: http://package-import.ubuntu.com/status
205+.. _`file a bug on the UDD project`: https://bugs.launchpad.net/udd
206+.. _`stable release update`: https://wiki.ubuntu.com/StableReleaseUpdates
207
208=== modified file 'udd-intro.rst'
209--- udd-intro.rst 2011-07-13 11:27:47 +0000
210+++ udd-intro.rst 2011-07-25 09:48:39 +0000
211@@ -1,202 +1,130 @@
212 ===================================================
213-Ubuntu Distributed Development - Getting the Source
214+Ubuntu Distributed Development - Introduction
215 ===================================================
216
217-*Ubuntu Distributed Development* (UDD) is a technique for developing Ubuntu
218+This guide focuses on packaging using the *Ubuntu Distributed Development* (UDD)
219+method.
220+
221+*Ubuntu Distributed Development* (UDD) is a new technique for developing Ubuntu
222 packages that uses tools, processes, and workflows similar to generic
223 distributed version control system (DVCS) based software development. The
224 DVCS used for UDD is Bazaar_.
225
226-You should already be familiar with basic Bazaar usage and workflow. For an
227-introduction to Bazaar see the `Bazaar Five Minute Tutorial
228+Traditional Packaging Limitations
229+---------------------------------
230+
231+Traditionally Ubuntu packages have been kept in tar archive files. A
232+traditional source package is made up of the upstream source tar, a "debian" tar
233+(or compressed diff file for older packages) containing the packaging and a
234+.dsc meta-data file. To see a traditional package run::
235+
236+ $ apt-get source kdetoys
237+
238+This will download the upstream source ``kdetoys_4.6.5.orig.tar.bz2``, the
239+packaging ``kdetoys_4.6.5-0ubuntu1.debian.tar.gz`` and the meta-data
240+``kdetoys_4.6.5-0ubuntu1~ppa1.dsc``. Assuming you have dpkg-dev installed it
241+will extract these and give you the source package.
242+
243+Traditional packaging would edit these files and upload. However this gives
244+limited opportunity to collaborate with other developers, changes have to be
245+passed around as diff files with no central way to track them and two developers
246+can not make changes at the same time. So most teams have moved to putting
247+their packaging in a revision control system. This makes it easier for several
248+developers to work on a package together. However there is no direct
249+connection between the revision control system and the archive packages so the
250+two must be manually kept in sync. Since each team works in its own revision
251+control system a prospective developer must first work out where that is and
252+how to get the packaging before they can work on the package.
253+
254+Ubuntu Distributed Development
255+------------------------------
256+
257+With Ubuntu Distributed Development all packages in the Ubuntu (and Debian)
258+archive are automatically imported into Bazaar branches on our code hosting
259+site Launchpad. Changes can be made directly to these branches in
260+incremental steps and by anyone with commit access. Changes can also be made
261+in forked branched and merged back in with Merge Proposals when they are large
262+enough to need review or if they are by someone without direct commit access.
263+
264+UDD branches are all in a standard location so doing a checkout is easy::
265+
266+ $ bzr branch ubuntu:kdetoys
267+
268+The merge history includes two separate branches, one for the upstream source
269+and one which adds the ``debian/`` packaging directory::
270+
271+ $ cd kdetoys
272+ $ bzr qlog
273+
274+(This command uses *qbzr* for a GUI, run ``log`` instead of ``qlog`` for
275+console output.)
276+
277+.. image:: images/kdetoys-udd-branch.png
278+
279+This UDD branch of *kdetoys* shows the full packaging for each version
280+uploaded to Ubuntu with grey circles and the upstream source versions with
281+green circles. Versions are tagged with either the version in Ubuntu such as
282+``4:4.2.29-0ubuntu1`` or for the upstream branch with the upstream version
283+``upstream-4.2.96``.
284+
285+Many Ubuntu packages are based on the packages in Debian, UDD also imports the
286+Debian package into our branches. In the *kdetoys* branch above the Debian
287+versions from *unstable* are from the merge with blue circles while those from
288+*Debian experimental* are from the merge with yellow circles. Debian
289+released are tagged with their version number e.g. ``4:4.2.2-1``.
290+
291+So from a UDD branch you can see the complete history of changes to the package
292+and compare any two versions. For example, to see the changes between version
293+4.2.2 in Debian and the 4.2.2 in Ubuntu use::
294+
295+ $ bzr qdiff -r tag:4:4.2.2-1..tag:4:4.2.2-1ubuntu1
296+
297+(This command uses *qbzr* for a GUI, run ``diff`` instead of ``qdiff`` for
298+console output.)
299+
300+.. image:: images/kdetoys-udd-diff.png
301+
302+From this we can clearly see what has changed in Ubuntu compared to Debian,
303+very handy.
304+
305+Bazaar
306+------
307+
308+UDD branches use Bazaar, a distributed revision control system intended to be
309+easy to use for those familiar with popular systems such as Subversion while
310+offering the power of Git.
311+
312+To do packaging with UDD you will need to know the basics of how to use
313+Bazaar to manage files. For an introduction to Bazaar see the `Bazaar Five
314+Minute Tutorial
315 <http://doc.bazaar.canonical.com/bzr.dev/en/mini-tutorial/index.html>`_ and the
316 `Bazaar Users Guide
317 <http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/index.html>`_.
318
319-
320-Source package URLs
321-===================
322-
323-Bazaar provides some very nice shortcuts for accessing Launchpad's source
324-branches of packages in both Ubuntu and Debian.
325-
326-To refer to source branches use::
327-
328- ubuntu:package
329-
330-where *package* refers to the package name you're interested in. This URL
331-refers to the package in the current development version of Ubuntu. To
332-refer to the branch of Tomboy in the development version, you would use::
333-
334- ubuntu:tomboy
335-
336-To refer to the version of a source package in an older release of Ubuntu,
337-just prefix the package name with the release's code name. E.g. to refer to
338-Tomboy's source package in Maverick_ use::
339-
340- ubuntu:maverick/tomboy
341-
342-Since they are unique, you can also abbreviate the distro-series name::
343-
344- ubuntu:m/tomboy
345-
346-You can use a similar scheme to access the source branches in Debian, although
347-there are no shortcuts for the Debian distro-series names. To access the
348-Tomboy branch in the current development series for Debian use:
349-
350- debianlp:tomboy
351-
352-and to access Tomboy in Debian Lenny_ use::
353-
354- debianlp:lenny/tomboy
355-
356-
357-.. _`Bazaar`: http://bazaar.canonical.com/en/
358-.. _`Intrepid`: https://wiki.ubuntu.com/IntrepidIbex
359-.. _Maverick: https://wiki.ubuntu.com/MaverickMeerkat
360-.. _Lenny: http://debian.org/releases/stable/
361-
362-
363-Getting the source
364-==================
365-
366-Every source package in Ubuntu has an associated source branch on Launchpad.
367-These source branches are updated automatically by Launchpad, although the
368-process is not currently foolproof.
369-
370-There are a couple of things that we do first in order to make the workflow
371-more efficient later. Once you are used to the process you will learn when it
372-makes sense to skip these steps.
373-
374-
375-.. _up-to-date:
376-
377-Ensure the source branch is up-to-date
378---------------------------------------
379-
380-Once you've determined which source package to work on, you should ensure that
381-the source branch for that package on Launchpad is up-to-date. Some package
382-imports fail for various reasons, and the `status of the package importer`_ is
383-always available online. If the source branch for a package you want to work
384-on is out of sync, you'll have to use ``apt-get source`` until the import of
385-that package is fixed.
386-
387-Let's say you want to fix a problem in Tomboy in Natty. First, find out the
388-latest binary package versions that are available::
389-
390- $ rmadison tomboy | grep natty
391- tomboy | 1.5.2-1ubuntu4 | natty | source, amd64, i386
392-
393-You've already seen how to :ref:`determine the source package corresponding to
394-this binary package <what-to-fix>`. For Tomboy, the binary and source
395-packages are both named ``tomboy``.
396-
397-Whenever the package importer processes a new source package version, it adds
398-a Bazaar tag corresponding to that new version. You can use this tag to
399-ensure that the import is up-to-date. To find the tag of the last revision
400-committed by the package importer, do::
401-
402- $ bzr log ubuntu:tomboy | grep ^tags | head -n 1
403- tags: 1.5.2-1ubuntu4
404-
405-By comparing the version number returned by ``rmadison`` and the tag added by
406-the package importer, we can see that the ``tomboy`` source package for Natty
407-is up-to-date.
408-
409-Here's an example of a package that is out-of-date. Let's say you want to fix
410-a problem in the ``initscripts`` binary package. First find out the
411-latest binary package versions that are available::
412-
413- $ rmadison initscripts | tail -n 1
414- initscripts | 2.87dsf-4ubuntu25 | oneiric | amd64, i386
415-
416-Then determine the source package corresponding to this binary package::
417-
418- $ apt-cache showsrc initscripts | grep ^Package:
419- Package: sysvinit
420-
421-Find the latest tag added by the package importer::
422-
423- $ bzr log ubuntu:sysvinit | grep ^tags | head -n 1
424- tags: 2.86.ds1-61ubuntu13
425-
426-Here we can see that ``2.86.ds1-61ubuntu13`` is older than
427-``2.87dsf-4ubuntu19`` so the source package is out of date, and in fact we can
428-verify that by looking at the status package for the package at
429-http://package-import.ubuntu.com/status/sysvinit.html.
430-
431-When you find such out-of-date packages, be sure to `file a bug on the UDD
432-project`_ to get the issue resolved.
433-
434-A feature in progress is for a warning to be automatically printed when
435-branching an out of date import, this will make the above obsolete.
436-
437-.. _branching:
438-
439-Creating a shared repository
440-----------------------------
441-
442-Okay, you want to work on the Tomboy package in Natty, and you've verified
443-that the source package is up-to-date. Before actually branching the code for
444-Tomboy, create a shared repository to hold the branches for this package.
445-The shared repository will make future work much more efficient.
446-
447-Do this using the `bzr init-repo` command, passing it the directory name we
448-would like to use::
449-
450- $ bzr init-repo tomboy
451-
452-You will see that a `tomboy` directory is created in your current working
453-area. Change to this new directory for the rest of your work::
454-
455- $ cd tomboy
456-
457-
458-Getting the trunk branch
459-------------------------
460-
461-We use the `bzr branch` command to create a local branch of the package.
462-We'll name the target directory `tomboy.dev` just to keep things easy to
463-remember::
464-
465- $ bzr branch ubuntu:tomboy tomboy.dev
466-
467-The tomboy.dev directory represents the version of Tomboy in the development
468-version of Ubuntu, and you can always ``cd`` into this directory and do a `bzr
469-pull` to get any future updates.
470-
471-
472-Getting a branch for a particular release
473------------------------------------------
474-
475-When you want to do something like a `stable release update`_ (SRU), or you
476-just want to examine the code in an old release, you'll want to grab the
477-branch corresponding to a particular Ubuntu release. For example, to get the
478-Tomboy package for Maverick do::
479-
480- $ bzr branch ubuntu:m/tomboy maverick
481-
482-
483-Importing a Debian source package
484----------------------------------
485-
486-If the package you want to work on is available in Debian but not Ubuntu, it's
487-still easy to import the code to a local bzr branch for development. Let's
488-say you want to import the `newpackage` source package. We'll start by
489-creating a shared repository as normal, but we also have to create a working
490-tree to which the source package will be imported (remember to cd out of the
491-`tomboy` directory created above)::
492-
493- $ bzr init-repo newpackage
494- $ cd newpackage
495- $ bzr init debian
496- $ cd debian
497- $ bzr import-dsc http://ftp.de.debian.org/debian/pool/main/n/newpackage/newpackage_1.0-1.dsc
498-
499-As you can see, we just need to provide the remote location of the dsc file,
500-and Bazaar will do the rest. You've now got a Bazaar source branch.
501-
502+Limitations of UDD
503+------------------
504+
505+Ubuntu Distributed Development is a new method for working with Ubuntu
506+packages. It currently has some notable limitations:
507+
508+* Doing a full branch with history can take a lot of time and network
509+ resources. You may find it quicker to do a lightweight checkout ``bzr
510+ checkout --lightweight ubuntu:kdetoys`` but this will need a network access
511+ for any further bzr operations.
512+
513+* Working with patches is fiddly. Patches can be seen as a branched revision
514+ control system, so we end up with RCS on top of RCS.
515+
516+* There is no way to build directly from branches. You need to create a source
517+ package and upload that.
518+
519+* Some packages have not been successfully imported into UDD branches. You
520+ should check the `status of the package importer`_ before working on a branch.
521+
522+All of the above are being worked on and UDD is expected to become the main way
523+to work on Ubuntu packages soon. However currently most teams within Ubuntu do
524+not yet work with UDD branches for their development. However because UDD
525+branches are the same as the packages in the archive any team should be able to
526+accept merges against them.
527
528 .. _`status of the package importer`: http://package-import.ubuntu.com/status
529-.. _`file a bug on the UDD project`: https://bugs.launchpad.net/udd
530-.. _`stable release update`: https://wiki.ubuntu.com/StableReleaseUpdates

Subscribers

People subscribed via source and target branches