What's the relationship between patches-to-packages and udd-patchsys?

Are we going to drop just one of them? Or how much will we need to add from one to the other?

Sorry for not getting to this earlier.

The real issue is that udd-patchsys and patches-to-packages both take fairly different approaches. We need to decide which we recommend.

udd-patchsys suggest hacking directly in the branch that exporting a patch with `bzr diff -p "a/:b/"` Then importing that back with `quilt import` and reverting the changes made directly to the files.

patches-to-packages uses the normal quilt workflow of `quilt new patch.diff`, `quilt add src-file`, hack, `quilt refresh`

My thought is that patches-to-packages is closer to what we want. While the way udd-patchsys recommends is pretty nifty, it seems to me that the patches-to-packages pure quilt workflow is more widely used. Anyone else have any thoughts?

udd-patchsys also has some info on edit-patch which we should probably retain (and maybe even expand a bit on using some of the old wiki content).

On Nov 13, 2012, at 08:02 PM, Andrew Starr-Bochicchio wrote:

>Sorry for not getting to this earlier.
>
>The real issue is that udd-patchsys and patches-to-packages both take
>fairly different approaches. We need to decide which we recommend.
>
>udd-patchsys suggest hacking directly in the branch that exporting a
>patch with `bzr diff -p "a/:b/"` Then importing that back with `quilt
>import` and reverting the changes made directly to the files.
>
>patches-to-packages uses the normal quilt workflow of `quilt new
>patch.diff`, `quilt add src-file`, hack, `quilt refresh`
>
>My thought is that patches-to-packages is closer to what we want. While
>the way udd-patchsys recommends is pretty nifty, it seems to me that the
>patches-to-packages pure quilt workflow is more widely used. Anyone
>else have any thoughts?
>
>udd-patchsys also has some info on edit-patch which we should probably
>retain (and maybe even expand a bit on using some of the old wiki
>content).

I have to be honest, for a while now I've essentially used the
patches-to-packages workflow. Quilt is a little awkward IMHO, e.g. you better
'quilt add' a file to the top patch before editing it, but it does seem to be
easier to work with quilt rather than fight it. The most important thing to
remember is that you must restore the quilt stack to the state of the original
package branch before trying to create the source package. IOW, if you `quilt
new` a new patch, before you `debcommit` or `bzr commit`, you have to do a
`quilt pop`. This is the only reliable way to avoid cluttering up the diff
with .pc directory crud.

One other thing I recommend: never, ever, push a udd branch. Just use the udd
branch to build the source package, and let the package importer generate the
new version once you've uploaded the source package. This seems way less
error prone to me. It does mean that I never make changes in my local working
dir of the udd branch. I always do something like:

 $ bzr init-repo thepackage
 $ cd thepackage
 $ bzr branch ubuntu:thepackage raring
 $ bzr branch raring bug12345
 $ cd bug12345
 <hack, hack, hack>
 $ bzr bd -S
 <build, build, build>
 <test, test, test>
 $ dput thepackage_X.Y.Z.dsc
 <wait, wait, wait>
 $ cd raring
 $ bzr pull
 <rejoice, rejoice, rejoice>