[Oneiric-Topic] Packaging branches

[Robert Ancell]

On 04/12/2011 06:34 PM, Martin Pitt wrote:
> Robert Ancell [2011-04-11 10:36 +1000]:
>> - People are often ignoring the branches and uploading directly (or
>> forgetting do a bzr push) which means changes are sometimes dropped by
>> accident
>> - People often do merge requests to lp:ubuntu/package_name, even when
>> there is a packaging branch
> I agree that these are annoying indeed.
>
> However, after having worked with the "normal mode" branches for a
> while, I still don't like them better:
>
>  * They come with quilt patches pre-applied in the source, which is
>    not only horribly confusing and error prone, but also breaks
>    merge-upstream pretty thoroughly.
I hadn't noticed that.  The seems like absolutely the wrong behaviour. 
Can this be fixed?
>  * They still ignore the actually interesting problem: maintaining
>    patches themselves with revision control, with
>    looms/threads/pipelines/name du jour. I. e. they throw all this
>    bzr overhead on the bits that we don't need in bzr (the upstream
>    code), but don't actually help us with patch management.
That certainly is the goal we want to get to sometime.  However I do
think they are easier to make patches.

Current method (perhaps I'm missing something here):
1. Checkout bzr branch of debian/ directory
2. Get tarball of current version (I use apt-get source, though you have
to be careful that it is the same version)
3. Get tarball of latest version (I use bzr-buildpackage and then ctrl-C
once I have the tarball in the build-area/ directory)
4. Unpack tarballs somewhere manually
5. Copy debian directory
6. Diff two versions for changes (i.e. NEWS and configure.ac) - I use
meld here
7. Update debian/rules debian/control etc
8. Muck around with quilt/edit-patch to add/update/remove patches
9. Copy back debian/ directory changes to bzr branch
10. bzr-buildpackage
11. debcommit / bzr push

Normal mode method:
1. Checkout branch of source and debian/ directory (Sloooooooooowwww
first time)
2. bzr merge-upstream
3. bzr diff to check for changes in package (i.e. NEWS and configure.ac)
4. Update debian/rules debian/control etc
5. Muck around with quilt/edit-patch to add/update/remove patches
6. bzr-buildpackage
7. debcommit / bzr push
>  * They are incompatible with upstream bzr branches even for those
>    projects whose native trunks are in Launchpad and bzr already.
Again, is this fixable?
> So in summary I must say that the main effect from the full branches
> is that people make a lot more errors and everything is slower :-(
>
> Martin