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

Axel Beckert abe at debian.org
Fri Feb 11 20:26:21 UTC 2011


Hi,

Frank Terbeck wrote:
> 1. Base the whole package on upstream's git mirror.

Sounds like a very good idea.

> 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'.

Why the tag here?

> 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'

Looks fine so far.

> % git diff heads/upstream..heads/debian | git apply
> % git add ./debian
> % git commit -m'Importing debian releated changes'

I'd definitely use a merge here.

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

Definitely.

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

Yeah.

> Could be based on zsh's git master branch and rebased.

Rebasing is evil if done on some published repo IMHO. I'd prefer merge
over rebase as much as possible.

> That way, building something like `zsh-beta' off of it would be
> fairly simple.

Wouldn't merge suffice here, too?

> 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).

Hmmm, now it gets interesting.

Basically, if we don't have the patches in here, I (more or less :-)
insist on this branch always being merged instead of rebased.

> 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.

I usually prefer to have one main branch and would cherry-pick or
(preferably) merge side-branches of the main branch for releases.
Otherwise I don't see how we would have a "red line" through our
commits and it look more like a saw tooth line.

> The only catch is the `debian' branch being rebased on top of
> `upstream' every once in a while.

That's what I dislike in this approach.

> 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.

Good, because I'd prefer that.

> It's just, that the history of the debian branch will look quite a
> bit messier, because of the merge commits).

Ehm, IMHO, it would look way less messier in gitk then. :-)

> 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).

Well, similar here. I'm using it on a few packages where I have
co-maintainers, but I suspect I don't use its up to it's potential.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5



More information about the Pkg-zsh-devel mailing list