[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