Calligra stable releases not in Debian stable Jessi

[Maximiliano Curia]

¡Hola Jaroslaw!

El 2016-09-30 a las 11:31 +0200, Jaroslaw Staniek escribió:
> I am maintainer of Kexi, one of Calligra apps. 
> I've just noticed that in Debian stable Jessi the recent Calligra is 2.8.5 
> which is 13 releases old. There are no updates to 2.8.7, and zero updates to 
> 2.9.*.

> 2.8.5 is a July 2014 version. Due to security and stability issues it may be 
> even better *not* to have this version released at all than receiving reports 
> and users thinking that's the most recent version (this is my own opinion).

> When users run, say, a Raspberry, they see that old and unsupported (by us) 
> version. So here Jessi distributes this unstable software despite many updates 
> being available. I don't see the same issue with MySQL for example, which was 
> updated just this month. Maybe a man power issue?

> I have questions then:
> - what happens?

Debian has a release cycle of around 2 years. It uses three separate tracks: 
unstable, testing and stable.

For the first ~20 months of this cycle the package maintainers make regular 
updates to unstable and testing, adding new software to the archive in order 
to prepare for the next stable release. Packages first go through unstable and 
after a while they enter into testing which is what will be eventually 
considered for the stable release.

The last part of the cycle is a freeze period where no new versions are 
introduced and all the efforts go to finish the integration of the system, 
closing as many bugs as possible, backporting upstream fixes, etc.

At the end of this cycle the release is tagged as stable and stops receiving 
updates, except for critical bugs, and security related issues. This updates 
are evaluated by the stable release team, and/or the security team, once 
accepted they are available in the proposed-updates or the security archives 
till the next stable point release.

Almost no software gets new versions in the stable release, very few 
exceptions are made for critical security bugs in software that's infeasible 
to backport the corresponding fixes (an exception was made for firefox some 
years ago, and also for mariadb not so long ago), this is actually a sign that 
there is something wrong with the software.


Jessie is currently the stable Debian version, the current testing version is 
called stretch, and is about to enter in the freeze stage.

> - what can be done to fix the situation?

The version of calligra that you point out is in the stable release and won't 
get updated to a new version. The package maintainers could decide to backport 
some critical fix.

Could you point out the issues that you consider critical in 2.8.5?

> - how to coordinate better?

There are two things that could be better improving coordination:

 - Notifying the package maintainers of critical issues that need to be fixed
   in the stable release.
   This could be done either through a bug or sending a private mail to the
   uploaders (which sometimes is needed for certain security related issues)

 - Coordinating on the version to release for the next stable release.
   The current version for stretch is: 2.9.11
   This could be changed if need so.

Regarding manpower, calligra is a big and scary (from the maintainers point of 
view) piece of software. In the past year, two different contributors tried 
working on it and gave up after a while, calligra was not in testing for a few 
months until finally someone else had the time to pick it up and uploaded it.

Given this situation, following upstream commits and announcements in order to 
evaluate whether they fix critical issues is currently infeasible. 
Collaborating with upstream would make this better.

Happy hacking,
-- 
"Seek simplicity, and distrust it." -- Whitehead's Rule
Saludos /\/\ /\ >< `/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20161008/896e66f7/attachment.sig>