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

[Reinhard Tartler]

Jelmer Vernooij <jelmer at samba.org> writes:

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

Ah, that's indeed a valid point I didn't think about before. Thanks.

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

Which is quite straightforward. I think we could extend bzr-builddeb or
bzrtools' import command to make this really straightforward.

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

Ah, it is easier for upstream, not for the packager. I see your point now.

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

ok. Since you are upstream, I of course agree that having another branch
with no common ancestors is indeed painfull. For packages where I don't
track upstream that closely however, ...

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

No, the tarball is always the one from upstream. I don't recreate tarballs.

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

Hm, since Robert also favors mode 1, let's stick to that, (at least for now).
-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4