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

[Axel Beckert]

Hi,

Frank Terbeck wrote:
> I've been throwing my initial proposal away entirely.
> 
> I have also been considering Axel's comments closely.

Thanks. :-)

That looks very closely what I had in mind. It is also a workflow
which is quite close to what git-buildpackage uses (IIRC just with
different branch names, but that's fine and configurable :-) which
again is what mika seemed to favor for packaging, at least git-dch is 
part of the git-buildpackage .

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

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

>    - Merge `upstream' into `debian'.

Can be done with git-import-orig.

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

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

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

> ** Generating packages
> 
>    I have been evaluating whether `gitpkg' could fit our workflow. And
>    I'm fairly sure it does.

Never used it, but doesn't sound bad. :-)

>    The tool is fairly flexible, but its basic usage is quite simple,
>    which is something I liked most about it.

Hehe.

		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