[Pkg-zsh-devel] [RFC] Repository workflow

[Frank Terbeck]

Hey *,

I've been looking at the current state of our repository. Here are my
thoughts about how to handle it in the future.


1. Base the whole package on upstream's git mirror.

IIRC, Clint suggested this, too, and i believe it's the right thing to
do. We should also do it now, before we're introducing any new changes
into the code base.

My idea would be to branch off deb-X.Y-Z branches when an upstream
release is tagged. The first commit should be a call to
`./Util/preconfig'. This commit should be tagged `deb-X.Y.Z.tar'. The
second commit after such a branch-off should be introducing
debian-related stuff in the `debian/' sub-directory.

That step could be automated. And fairly easily:

% git checkout -b deb-4.3.12 zsh-4.3.12
% ./Utils/preconfig
% rm -Rf autom4te.cache
% git add -f config.h.in configure stamp-h.in
% git commit -m'Generating configure script'
% git diff heads/upstream..heads/debian | git apply
% git add ./debian
% git commit -m'Importing debian releated changes'

...or something along those lines (this snippet assumes the two next
points are followed, too).


2. Don't patch the source. Use `debian/patches/*' and quilt.

Personally, I'm feel that approach to be infinitely more elegant than
anything else I've seen.


3. Keep `debian/*' in a separate branch.

Could be based on zsh's git master branch and rebased. That way,
building something like `zsh-beta' off of it would be fairly simple.

The `debian/patches/' directory should not be in that branch since
patches to the source always depend on which release we're patching
(unless we want permanent changes from the upstream code base).


So basically the repository would look like this:

   - upstream: tracks zsh's git mirror
   - debian: rebased onto `upstream' adding the `debian/' directory
   - deb-4.3.11: branched off the commit where the 4.3.11 release
     happened upstream; The first commit should run `Util/preconfig'
     and generate a `configure' script. The data, the `debian' branch
     adds on top of `upstream' needs to replayed into this branch in
     its second commit.

That way we can get to every point in every release. When work is being
done in the `debian' branch, those commits can trivially be
cherry-picked into the release-specific one.

To build packages off of that setup, we'd only need to create a tarball
from a branch. I've been told pristine-tar can do that. It should do it
off of the `deb-X.Y.Z.tar' tag.

The only catch is the `debian' branch being rebased on top of `upstream'
every once in a while. But that's not really an issue, of that condition
is made clear within the team (actually, we could also merge upstream
into debian every once in a while - that shouldn't make a difference for
the rest of the concept. It's just, that the history of the debian
branch will look quite a bit messier, because of the merge commits).

Also, I'm running git-HEAD builds of zsh on my laptop and am therefore
able to make sound judgements when to rebase again. Rebases should be
announced on the mailing list beforehand.

I'll try to setup a proof-of-concept repository during the afternoon. No
promises on how far I'll get, though. :-)

When everything is in place the way I got it in mind, to build a
package, you'd do this:

% QUILT_PATCHES=debian/patches
% export QUILT_PATCHES
% git checkout deb-4.3.11
% quilt push -a
% debuild -us -uc
% quilt pop -a
% git clean -xdf


You're obviously welcome to tell me if I'm making a fundamental mistake
here. Also, I'm not familiar with how well git-build-package works these
days. When I looked at it a while back, I walked away pretty quickly. If
you're currently using it, I'd be interested in how it works (ie. how
the gbp workflow looks like).

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925