[Pkg-e-devel] evert "Add configuration file for git-buildpackage"

[Jan Lübbe]

On Tue, 2008-02-19 at 01:41 +1100, Niv Sardi wrote:
irc discussion:
> 01:06 < xaiki`> Shoragan: the 'workflow' tryes to be the one gbp has been 
>                 designed for...
> 01:06 < xaiki`> aka upstream in upstream.
> 01:06 < xaiki`> debian in debian
> 01:07 < xaiki`> and master being our devel (on the upstream) branch
> 01:07 < xaiki`> idealy we should need NO config file.
> 01:08 < Shoragan> then we need different tags (instead of v0.1.2)
> 01:12 < xaiki`> yep, I took your idea.
> 01:13 < xaiki`> and switch do upstream/version
> 01:13 < Shoragan> what do you mean by devel on the upstream branch?
> 01:13 < xaiki`> if we need to patch upstream.
> 01:13 < xaiki`> we do it in master.
> 01:13 < Shoragan> ah
> 01:13 < xaiki`> so we don't break the git logic.
> 01:13 < Shoragan> thats the problem
> 01:13 < xaiki`> and our tree is a full git devel tree.
> 01:13 < Shoragan> we probably need to rebase the patches branch some times
> 01:14 < xaiki`> the idea is that we can tell upstream: pull from our master
> 01:14 < xaiki`> master is the patch branch =)
> 01:14 < Shoragan> they use cvs internall, so no direct pulling
> 01:15 < xaiki`> in the way that every upstream pull has to be followed by a 
>                 rebase.
> 01:15 < xaiki`> well they use CVS now =)
> 01:15 < xaiki`> there is no harm in designing the workflow to the assumption 
>                 they'll stop killing puppies.
> 01:16 < Shoragan> ok
> 01:17 < Shoragan> my idea was to have upstream/vxxx tag on the pure upstream 
>                   repo,
> 01:17 < xaiki`> we can't build on pure upstream.
> 01:17 < xaiki`> as we need to relibtolize.
> 01:17 < Shoragan> and then 'our' vxxx tags to tag the autotoolized 
>                   (upstream-patches) branch, whicht would get packaged into the 
>                   orig.tar.gz
> 01:18 < Shoragan> so that the orig.tar.gz is at least buildable
> 01:18 < xaiki`> what does this 2 tags bring us ? they are allways only 
>                 separated by a relibtoolization.
> 01:19 < xaiki`> 'our' tags shall be the debian state when uploading 
> 01:19 < Shoragan> we can rebase upstream-patches and have master as a 
>                   continuous integration branch
> 01:20 < Shoragan> by repeatedly merging upstream-patches onto master
> 01:20 < xaiki`> well everytime we upload a orig to debian, we create a branch.
> 01:20 < xaiki`> and we rebase master on upstream.
> 01:20 < xaiki`> I don't see the need of upstream-patches
> 01:21 < Shoragan> ok, lets try your approach :)
> 01:22 < xaiki`> if you see any real issue please let me know =)
> 01:22 < Shoragan> but in the long term debian should pick one aproach to git 
>                   packaging, this is getting confusing
> 01:22 < xaiki`> AGREED.
> 01:22 < xaiki`> this is my rationale:
> 01:23 < Shoragan> i'll bring that up in the vcs-packaging talk at fosdem next 
>                   week
> 01:23 < xaiki`> in git world, people develop the code in 'master'
> 01:23 < xaiki`> we should do too.
> 01:23 < xaiki`> our work for debian, should be in debian/
> 01:24 < xaiki`> so that we always look like a code tree to upstream, as 
>                 upstream doesn't give a shit about debian dev =)
> 01:24 < Shoragan> when using feature-branches (which we sort of do with our 
>                   debian branch) most people use master for integration, so 
>                   that after cloning the repo you have the buildable source in 
>                   master
> 01:24 < xaiki`> so debian stuff HAS TO STAY OUT of master and upstream has to 
>                 be untouched.
> 01:24 < xaiki`> we don't want debian/ upstream.
> 01:24 < xaiki`> we busted raster's balls to remove them =)
> 01:25 < Shoragan> so on which branch do you merge debian and the upstream code?
> 01:26 < xaiki`> you format-patch upstream..master and put those patches as 
>                 files in debian
> 01:26 < xaiki`> when ready to upload, you create a branch where you 
>                 relibtoolize.
> 01:27 < xaiki`> and tag it.

This does not repesent that is in the git trees at the moment. Currently
we have no patches in git.

> 01:27 < Shoragan> thats quite different from git-buildpackage
> 01:27 < xaiki`> that's how I did understand it, if you have another model 
>                 please expose =)
> 01:28 < xaiki`> (but git-buildpackage does build what I want =P)
> 01:28 < Shoragan> but with git-buildpackage you don't have the suff git 
>                   format-patch produces, just one big diff.gz
> 01:28 < xaiki`> yeah, that sucks.
> 01:28 < xaiki`> dead to the evil !
> 01:29 < xaiki`> I don't want to make ubuntu-like packages.
> 01:29 < xaiki`> people that come after us should see our patches.
> 01:29 < xaiki`> it's easy to do, no need to force them to use git to extract 
>                 our patches.

If upstream needs a commit from git they could just use gitweb (and get
it as a patch with something like
http://git.debian.org/?p=pkg-e/libs/eet.git;a=commitdiff_plain;h=586e6ec96b78b2af62a282ea3408a46873fa7606)
or use git-cherry-pick. This also preserves the context of the patch
much better.

> 01:31 < Shoragan> but it's not easy to reproduce your diff.gz from git without 
>                   knowing your workflow... thats not optimal
> 01:31 < xaiki`> hum it actually is.
> 01:31 < xaiki`> checkout debian
> 01:31 < xaiki`> git-buildpackage.
> 01:31 < xaiki`> done.

Which does not work right now without parameters to gbp or at
~/.gbp.conf.

git-buildpacke while on branch debian will complain:

~/git/debian$ git clone git://git.debian.org/git/pkg-e/libs/eet.git
...
~/git/debian$ cd eet/
~/git/debian/eet$ git checkout -b debian origin/debian
~/git/debian/eet$ git-buildpackage -us -uc
test -x debian/rules
test "`id -u`" = 0
for i in ./config.guess ./config.sub  ; do \
		if test -e $i.cdbs-orig ; then \
			mv $i.cdbs-orig $i ; \
		fi ; \
	done
/usr/bin/make -C . -k distclean
make[1]: Entering directory `/home/jluebbe/git/debian/eet'
make[1]: *** No rule to make target `distclean'.
make[1]: Leaving directory `/home/jluebbe/git/debian/eet'
make: [makefile-clean] Error 2 (ignored)
rm -f debian/stamp-makefile-build
rm -f debian/stamp-autotools-files
dh_clean 
rm -rf ./doc/html ./doc/latex ./doc/man
rm -rf ./eet_docs.tar.gz*
You are not on branch 'master' but on 'debian'
Use --git-ignore-new to ignore or --git-debian-branch to set the branch name.
~/git/debian/eet$ 

This is because gbp expects the debian packaging to be on 'master' by default
(see /etc/git-buildpackage/gbp.conf).

We can use a .gbp.conf in our repo to tell it where to look, and i think
it is possible to keep that file out of the .diff.gz. (which we should,
because it is repository metadata, not package metadata).

> 01:32 < xaiki`> as your version tag points to the relibtoolize branch you get 
>                 the right orig, and the right diff.

This is good because it makes the orig.tar.gz buildable on its own.

> 01:32 < Shoragan> but it breaks the flow of git commits from master to debian
> 01:32 < Shoragan> (by having them as patches)
> 01:32 < xaiki`> you're assuming you hack on debian/ in master.
> 01:32 < Shoragan> no
> 01:32 < Shoragan> i.e. the relibtoolization commit
> 01:32 < xaiki`> debian ships patches in debian/patches
> 01:33 < Shoragan> thats not mandated by policy
> 01:33 < xaiki`> once you relibtoolize you are not going to upload another .orig
> 01:33 < xaiki`> that's mandated by common sense =)
> 01:33 < xaiki`> and for the sake of hackability.
> 01:34 < xaiki`> so as you don't need another orig, the ONLY addition are 
>                 patches in debian/

When using git-buildpackage, all differences on the current branch
relative to the upstream/0.9... tag will be represented in the .diff.gz
(not just the stuff in debian).

> 01:34 < xaiki`> but I might see a flow.
> 01:34 < xaiki`> flaw*
> 01:34 < xaiki`> but I'm too tired to think about it now.
> 01:34 < xaiki`> I'll send this in mail, and we'll continue discussing later.

An open point is this:
If i understand xaiki corrently, he would like to have seperate patches
in the debian branch.

I would like to simply use git for everything, and let git-buildpackage
handle the rest. This would simplyfy the workflow for us, but DDs making
NMUs without using git would have all changes munged together.
I think we should focus on our workflow because:

* Using debcheckout to get the full repo is easy
* Having patches in git makes merging harder and obsures the git
history/diffs
* The gbp tools are still in development and will probably support
either a new source format (joey's git.gz) or output as a patch stack
later.
* We are maintaining the packages as a team in git, so other people
shouldn't have to NMU our packages because we are responsive enough.

-- 
Jan Lübbe <jluebbe at lasnet.de>            http://sicherheitsschwankung.de
 gpg-key      1024D/D8480F2E 2002-03-20
 fingerprint  1B25 F91F 9E7B 5D4F 1282  02D6 8A83 8BE4 D848 0F2E