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

[Axel Beckert]

Hi,

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.

That's the point.

> And since this is not very hard to do, we probably just should do
> it.

Well, it would make recognising permanent patches by filenames a
little bit more ugly ("ls ??_deb_*"), but that's 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.

Hey, I didn't know that subcommand. Cool! :-)

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

I was wrong. I thought of importing .tar.gz upstream archives, not of
having the upstream git repo available.

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

Just forget it. :-)

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

Because the debian/$upstreamversion-$revision commonly points to that
commit from which the uploaded package was built.

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

Sure. That's exactly what I described but not what I understood in you
first description. So maybe we just don't understand each other
correctly and we think of the same, but just say it with ambiguous
words confusing each other. :-)

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

Ok, so that's the real difference in our ideas.

I'd usually include in a -1 package also bugs whose fixes are pending
at that time.

An upstream release is usually a reason for a new upload while just
some minor bugs are not a reason. I usually first prepare the new
upstream version, then check which bugs have been fixed by upstream
(should be added to changelog, which will be another commit between
merge or import and upload plus tagging), then check the remaining
open bugs for those whose fix should be included (some more commits)
and then, when the package's state pleases me, I finanlize the
changelog entry (date update, another commit), build the package, test
it, upload it and as a last step, tag what really has been uploaded.

Because if I find some issue during testing I would have to move the
tag to a later commit which is something I'd like to avoid. (Ok, no
big problem, if I have not yet pushed the tags, but nevertheless I try
to avoid that case.)

		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