[Pkg-zsh-devel] [RFC] Git workflow, take #2

[Frank Terbeck]

Axel Beckert wrote:
> Frank Terbeck wrote:
[...]
>> ** Working on the package
>> 
>>    Every change to the source (non-debian-dir) should be done by
>>    adding quilt patches. Permanent patches (patches that would be kept
>>    in 4.3.12-1) should be named specially ("deb_*" comes to mind).
>
> Good idea.
>
> Another idea which comes to my mind is that patches may or may not be
> labeld with numbers to show the order of appliance. Depending on how
> many patches we have, this may become necessary. (I'd say with more
> than a dozen patches, it becomes helpful.)

Yes, I thought about that as well. It's not really needed because quilt
could list the patch series correctly... However it may be convenient,
to see the order in a quick "ls", too. And since this is not very hard
to do, we probably just should do it.

>> ** Transitioning to a new upstream version
>> 
>>    When upstream releases a new version, we should follow these steps:
>> 
>>    - Remove all non "deb_*" quilt patches (because the non-permanent
>>      patches should be included in the upstream version already).
>
> This sounds pretty bad. On the one side "Remove all" and on the other
> side "should". IMHO this opens a door for a lot of bugs to pop up
> again and again every second upload. I'd reword this as follows:
>
> | Remove all non "deb_*" quilt patches which have been applied upstream.
>
> That's precise and prevents regressions of already fixed bugs.

Fair enough.

We may be able to use git-notes to keep track of which patches have been
applied upstream and which have not.

>>    - Merge `upstream' into `debian'.
>
> Can be done with git-import-orig.

Okay. But why? What is the advantage of just using git-merge?

>>    - update debian/changelog, "New upstream release".
>
> Probably can be automated, too. I thought that git-import-orig can do
> that, but --postimport=command which could call git-dch or so.

Yes. I'd like to automate the autotools-generated stuff, too. Shouldn't
be too hard.

>>    - Tag debian/<new-zsh-version>-1.
>
> No. Not at that point already. 
>
> This should only be done directly after the finally build package has
> been uploaded. Can be done with git-buildpackage.

Um. Why? I don't see any advantage in doing that. Actually, I'd kind of
like to be able to say, which commit is what debian revision.

> Additionally all other changes to the package should be done before
> tagging, too. (I'd expect that we seldomly just upload a new upstream
> version without any other packaging changes.)

Obviously, if there is the need for additional changes in -1, they
should be included, too. But I'd actually expect -1 to be an upstream
release without additional changes (other than permanent patches).

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