[Pkg-giraffe-maintainers] Kopano update

[Carsten Schoenert]

Hello Fabian,

Am 16.10.21 um 22:16 schrieb Fabian Stanke via Pkg-giraffe-maintainers:
> Dear Giraffe Maintainers
> 
> I’d be interested in contributing to achieve a build of Kopano 8.7.24
> on Debian stable (Bullseye).

in case you are not aware of the Debian rules about updating packages in
stable releases, typically no simple version updates are allowed and
practiced in Debian. Only a few exceptions are done, Kopano isn't
falling in this category to me.

To update a version in stable you want to fulfill one or more points of
the following list.

* Fixing one or more CVE for the current version in stable.
* Fix a user regression or misbehavior of the current version.
* Update the package due depending packages have been changed and the
  update is needed to prevent data loss or miss function in your
  package.
* Upstream has abandoned the used release and only support newer
  versions and supporting the older version is quite impossible.

So to shorten it a bit, it might become difficult or impossible to
update the current Kopano version in stable just for providing a newer
version.

In any case the responsible package maintainer need to explain the
release team why a update is needed and what effects this has. Means you
need to convince the RT that the update is required and will not effect
other packages and their maintainer.
The RT will decide if they accept the update.

A probably "easier" option is to provide updates via Backports. But
there are also rules to make this happen.
Main rule for providing packages by Backoprts is simply that the
backported version needs to be existing in testing. And of course here
too the package maintainer needs to be available in case further action
is needed or user doing bug reports.

> What branch structure should be used? My understanding is that it
> should be upstream/oldstable for Kopano (9 being stable and 11 being
> latest) and debian/bullseye for the build.

Given that no matter which way will be used and every new update will
need to go through unstable/testing I'd say currently no new workflow
and switching of branches is needed. Just use the current layout and
start your work in unstable/testing. As README.source isn't up to date,
basically the following steps are needed to work in a new version into
debian/sid.

* Import a new upstream version by using gbp import-orig
  /path/to/kopano-version.tar.xz
* Adjust the patch queue
* (Re)work current lintian issues
* Update or write new documentation for maintenance of the package
* Update the various files under debian/
* Test the packages
* If possible enhance the autopkgtests
* Update the package in unstable finally

> What would you suggest me to do? Should I submit a PR on salsa?
> Should I first host a private repository first for testing?
Yes please.
We've no knowledge how experienced about packaging you are so it's best
if you currently start working in a forked repository within your name
space.
It's no problem to switch between remote repositories to follow your work.

If not seen please note that almost all Kopano related packages are
orphaned. So providing a better user experience will mostly end in
required updates for other packages as well. We will try to help on this
much as possible if that help to take over maintenance of the packages.

The bug about orphaning kopanocore can be found here:
https://bugs.debian.org/976707

-- 
Regards
Carsten