[Pkg-giraffe-discuss] Z-push: Q about bug fix

[Carsten Schoenert]

Hi,

Am 06.02.18 um 14:31 schrieb Guido Günther:
> I usually track experimental on debian/experimental and merge back on
> forth between d/sid and d/experimental.

yeah, that's probably the safest way. The assumption for preparing the
2.4.0beta version on debian/sid was a expected quickly afterwards
release of 2.4.0. But this wasn't happen.

O.k. means for the future we should *always* package Betas RCs and
Snapshots on debian/experimental.

>> I couldn't find any info on that in the maintainers guide. So any pointers
>> or a high-quality package that I can use as an example are much appreciated!
> 
> Three solution:
> 
>  1 fix the bug in 2.4 and upload that to d/sid
>  2 create a branch and fix it there. d/testing sounds like a reasonable
>    name although you still upload to unstable.
>  3 create the branch only locally and only push the tags not the branch
>    itself. 
> 
> 3.) looks like the cleanest to me if the lifetime of 2.3.8 in
> testing/sid is only about one or two months. It gets tedious if you need
> to fix more stuff.

Normally I'd vote for the first bullet. But the whole thing seems a bit
more unneeded complicated than I thought on a first view. Due the
changes in kopano-core in 8.5, just released this week on Monday, some
changes for z-push 2.3.8 are needed.

http://z-push.org/z-push-2-3-8-final-release-update/

I've planed to prepare the recent kopano-core version 8.5.0 while this
week somehow and upload this to unstable. Then z-push in the testing
archive is affected by the needed update of z-push as the website on
z-push.org is mentioning. But I have no idea why not a version 2.3.8.1
or 2.3.9 is released by z-push.org, or 2.4.0beta2. Maybe some of the
guys from Kopano can say something about this.
If there is a release of version 2.4.0 planned by z-push I'd do adding a
Breaks to kopanocore on z-push (<< 2.3.8-2.1~) and wait until 2.4.0 can
be added to unstable.

Otherwise I see a forth possible solution of the branching problem to
import the updated version 2.3.8 into debian/sid.

Create a new branch debian/experimental based on the tag
'debian/2.4.0_beta1-1'.
Then revert all commits on debian/sid so you are back on 'debian/2.3.8-2'.
Now import the updated version of the upstream source and do the fixing
of the bug report on top of the updated debian/sid branch.

By this we would have the debian/experimental branch existing for later
usage on other upstream versions for the experimental archive but can go
on with the current package version in unstable.
Not really nice but acceptable I think.

-- 
Regards
Carsten Schoenert