[Pkg-zsh-devel] [RFC] Git workflow, take #2
Frank Terbeck
ft at bewatermyfriend.org
Fri Feb 18 13:56:51 UTC 2011
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
More information about the Pkg-zsh-devel
mailing list