[Pkg-bazaar-maint] bzr-gtk is a release behind

[Jelmer Vernooij]

Reinhard Tartler wrote:
> Jelmer Vernooij <jelmer at samba.org> writes:
>> On Thu, 2007-05-24 at 14:22 +0200, Reinhard Tartler wrote:
>>> Wouter van Heyst <larstiq at larstiq.dyndns.org> writes:
>>>
>>>> http://pkg-bazaar.alioth.debian.org/0.16/ has bzr-gtk 0.16.0
>>> I've imported the bzr-gtk package as described at
>>> http://wiki.tauware.de/misc:vcs-packaging to 
>>> sftp://bzr.debian.org/bzr/pkg-bazaar/bzr-gtk/unstable
>>>
>>> I also uploaded bzr-gtk to unstable.
>> Any reason for not using the upstream branch here? The upstream branch
>> is neither big, nor does bzr-gtk require any autogenerated files that
>> are not versioned. 
> Thanks for bringing up the discussion. I've outlined 3 possible modes of
> maintaining a package here: http://wiki.tauware.de/misc:vcs-packaging
> 
> Currently, the packages bzr and bzrtools are maintained using mode 1
> (debian/ directory only), bzr-svn and bzr-builddeb in mode 2 (complete
> upstream history), and bzr-gtk in mode 3 (upstream releases
> only). Jelmer now proposes to use mode 2 for bzr-gtk as well.
> 
>> Using the upstream branch (which sets tags for releases) makes a couple
>> of things easier:
>>
>>  * seeing what changes are missing from upstream (or debian) can be done
>> using bzr diff
> This is also possible quite easily with mode 3. you just need to know
> the revision, in which the latest upstream version was imported. Tags
> can help here.
That will only help diff against upstream releases, not against upstream
branches. For example, if I had a branch that fixed an important bug and
wanted to import that into the Debian package, I could simply run 'bzr
diff' or 'bzr merge' against that branch in mode 2. In mode 3, running
'bzr diff' against that branch will give you an error - as there are no
common ancestors.

>>  * updating to the next upstream is just a 'bzr merge
>> -rtag:bzr-gtk-0.16.0' command, 
> This is also possible with mode 3. 
Well, only if you've downloaded a tarball from $location, made sure it
hasn't tampered with, and imported it.

>>  * it makes it easier for upstream to cherry pick changes that are
>> available in the debian branch
> Why is it easier? I need to manually verify each patch anyway. What am I
> missing here?
Upstream would then be able to run 'bzr diff .
http://bzr.debian.org/path/to/bzr-svn-package' to see what changes the
debian package includes that aren't in upstream. With mode 3, this
breaks (no common ancestry).

Mode 2 is also nicer in that (as upstream maintainer) I don't have to
have more bzr-svn branches around that share no ancestors whatsoever
with the other branches.

>> By extending bzr-builddeb, we could even not have to worry about
>> upstream at all, since bzr-builddeb can simply generate the .orig.tar.gz
>> by doing something along the lines of 'bzr export
>> -rtag:PROJECTNAME-VERSION PROJECTNAME_VERSION.orig.tar.gz'.
> Indeed, this work. However, I think that .orig.tar.gz should only be
> created by upstream himself, since he should keep the authority to bless
> releases. If we create the .orig.tar.gz, we would probably end up with a
> tarball with another md5sum. This way you cannot verify the tarball
> anymore.
In mode 3, you import and later recreate the tarball - that may have a
lot of similar issues.

In the case of bzr-gtk and bzr-svn, the upstream tarball is always
created by using 'bzr export -rtag:bzr-gtk-$VERSION
bzr-gtk_$VERSION.orig.tar.gz', so using tags there should not be a problem.

> Having said this, does anybody object to maintain bzr and bzrtools with
> mode 3?
I would personally very much like to see them in either mode 2 or mode 1.

Cheers,

Jelmer