Calligra stable releases not in Debian stable Jessi

Sat Oct 8 22:48:21 BST 2016

On 8 October 2016 at 15:13,

Maximiliano Curia <maxy at debian.org> wrote:

> ¡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?
>
> 
Thanks for the explanation Maximilian.

If I can summarize (maybe not just for you as you have in-depth
understanding but more like for users and people from the outside of our
projects). If I understand correctly, the 'stability' term used by Debian
is a distribution-oriented one. Do you agree that releasing stability fixes
for a software, not just serious security fixes is a part of maintaining
software stability?

Even if we're staying with Kexi as an example, because of better
familiarity, let's look at its basic 24 months+ -old changelog of version
(not present in Debian stable):
https://www.calligra.org/news/calligra-2-8-6-released/

It was *really* surprising for me that Debian Stable has no 2.8.7 in the
offer. Knowing the idea of freezing already, I have not asked for 2.9.x but
we have semantic versioning and release cycles for a purpose to serve
better and predictably.

It's clear that Kexi, even if updated to 2.8.6 is more stable than 2.8.5,
right?
Obviously there are fixes of "I can't use the software anymore" category.
Are these fixes critical? Yes, if actual *using* the software for a
practical purpose is the goal, not ability to have any version installable.
If you're asking about security threats removed, there are such beasts,
please refer to my examples for the 2.8.7 release given in this thread.

Regarding "I can't use the software anymore" kind of bugs. As MS discovered
long ago with the beloved Office 97, users run something like 20% of the
functionality but everyone uses slightly different 20%. So also Kexi and
Calligra offers a huge feature set, as any integrated software package;
possible applications/combinations are hard to imagine or predict.
No doubt there are users for whom versions 2.8.[0-5] contain critical
issues in features they depend on so the software in that version as a
no-go for them.

What's user's perceived definition of stability is an open question. I have
my opinion here as I am usually trying to take the user's side. I'm not in
position to influence how distributors implement their mission. So feel
free to just use this long reply as justification of why these stories can
convince developers to prefer more direct distribution channels, closer to
the project's own channels.

I can clearly and naively say that in my 'stability/security book', keeping
an offer based on years-old software isn't a good service for my users.
Regardless of how many updates appeared since and how much effort it was.
We're using semantic versioning and support window for a reason. Now in
September 2016 not only 2.8.x but also 2.9.x series aren't receiving
updates anymore. So calling them stable is a kind of creating an archive.org
for a software. If that's the intent, fine with me.

If analogies have any purpose, let's use one. Apart of the FOSS factor, I
can't see much of a difference between:

1. Offering the unsupported Windows XP version when shipping new PCs in
2016.

2. Offering the unsupported FOSS apps by Debian in 2016 with a "stable"
sticker on
   -- where a logical kind of a fine print in the box reads that the
distribution is stable as the package definition level and such, not at the
software level. No doubt the software, like Kexi 2.8.5 was the *most*
stable at the time of release. But it's no longer the most stable out of
all *easily* available software. 2.8.6 is more stable, for some users
indefinitely more. It has the same build- and runtime dependencies. 2.8.7,
the last in the series, is even more stable. You stay with 2.8, you use
2.8.7, there can't be more conservative approach. Unless a distro does not
want to be in the same category of "distributing art" as distributors of XP
from 2016.

OK, it's possible to find the #2 case even more surprising than #1 because
#1 just a business as many other, not a service for better future, with
ideology nor a political movement. If there are consumers, there are
services for them. For 2# we're effectively ending up with a loose-loose
attitude.

So yes, for #2, users are assured that everything properly installs and
runs on supported hardware. Possibly on a 2005 hardware because e.g.
graphical hardware for Krita evolved since.
Good enough but what that means? I am afraid it strictly depends on
software we're asking for. In case of Calligra there were cases when 4
months meant much more usable result. In contrast, for mature projects,
good enough is really good enough. Python 2 or some older PHP is a good
enough offering even if I believe the creators would like to see the
upgrades faster moving forward.

Anything can be done with this opinion but I'd like to say, if there's
choice, keeping unsupported release or not, I'd be even in favour of not
keeping the old versions distributed at some point. Even if it means "no
such software anymore in the distro". If it's not possible all app
developers can do are red banners appearing after 2 years with a warning
that 'the software is no supported anymore'. No jokes. That's a honest
message, isn't it?

In other words, today Debian stable "supports" Kexi software that's not
supported anymore (I don't generalize as other software can be more mature
so it's not getting old as quickly and this one). And in contrast Debian
marks newer offerings as "unsable" when in fact the software may be (and in
case of Kexi is) the most available to date. Or maybe we're just discussing
about the definitions only?

Looking back I've not seen a single endorsement for the approach of not
updating the 2.8.x versions. And conversely, I've faced difficult opinions
that the software is not working as expected. Because of a defect X, fixed
(say) 20 months before, even if not available in the system declared as
"stable". Such bug reports end up on the application developer's desk. And
so on, that's another brick in the wall, on the other side is the year of
desktop Linux...

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

Good, is email to kde-announce-apps at kde.org enough?

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

I've heard about (lack of) the manpower only recently, that was a
motivation to start the thread. Only recently because I am not too frequent
user of Debian. But now hearing about the complexity in addition to the man
power issue, is not easy to me. We're talking about a compact modular
software that happened to run on 2009 mobile devices and, created in 1997,
is one of the first FOSS office suites around. Compactness and
architectural thinking seems to be a DNA of the project. It's not a
re-licensed code drop that appeared overnight.

I would be quite happy if we manage to find reasons for the inertia or even
dementia because in my eyes it harms the entire FOSS in general. However I
am also well prepared to a "nothing happens" scenario.

It's even hard to see the manpower issue as a critical one. The delay can
be 6, 12 months but 24 months? With no plans? Some other competing packages
such as LibreOffice (and before OpenOffice) depend (for some of its fairy
critical functionality) on so large (not scary?) blobs as Java and (as it's
the case of forks of proprietary software), even still have own graphical
frameworks not in line with anything Debian uses to display the UIs; the
build system has been known as custom, etc. etc.

> 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.
>
>
Anything that works: I am looking forward to move closer to how releases
for Ubuntu/derivatives, Windows or Mac are ultimately going to work:
packages available for the users the same week the source code is tagged.
After all why would is the distribution of the software taking so much
effort and brings discussions when the actual development should be, I
believe, the 99.9% part of the cost?

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20161008/ed18521b/attachment.htm>