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

[Frank Terbeck]

Axel Beckert wrote:
[...]
>> 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?

I didn't look at pristine-tar yet, but I thought it'd be a good to be
able to have a name on the commit we're producing tarballs out of.

[...]
>> % 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.

Well, if we'd let the debian branch walk along with the upstream branch,
we would be pulling in upstream changes, too. The code above would make
sure that doesn't happen. Also, we don't need all the debian-changes
history in these branches, because we got it in its own branch.

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

Rebasing isn't evil per-se. Actually, some projects do use the approach
exclusively (IIRC, the wine project does).

That being said, I'm generally against rebasing published work. But I
believe it would make sense here, because the debian branch would be an
add-on on top of upstream. It does not have anything to do with
upstream's code, so we do not need the benefits, which we'd get from
merge-commits.

If we'd rebase on top of upstream every once in a while, we'd be having
a clean and linear history on top of what we're packaging. I think that
for this use-case, rebasing is the cleaner approach.


>> That way, building something like `zsh-beta' off of it would be
>> fairly simple.
>
> Wouldn't merge suffice here, too?

Yes, I think it would.

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

With the approach I've been describing, you would have a very clear view
of the general work we're doing in the debian branch and release
specific changes in the release-specific branch.

There is only one thing that doesn't work elegantly in this concept, and
that's the changes to `debian/changelog'. I didn't think of that earlier
and it's actually quite a strong argument against this concept. We could
merge or cherry-pick those changes from the release-specific branch back
into the debian branch, but that could blow up if that's not being every
time there is a change in a release-specific branch. That's not elegant
at all.

[...]
>> You're obviously welcome to tell me if I'm making a fundamental mistake
>> here. [...]

I don't think there is much of a point in discussing this concept any
further if there is no clean solution to the changelog problem. I don't
see any.

Other ideas on possible work flows?

Regards, Frank