<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 October 2016 at 15:13, <div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">​​</div>Maximiliano Curia <span dir="ltr"><<a href="mailto:maxy@debian.org" target="_blank">maxy@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">¡Hola Jaroslaw!<span class="gmail-m_4824271276728494462gmail-"><br>
<br>
El 2016-09-30 a las 11:31 +0200, Jaroslaw Staniek escribió:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.*.<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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).<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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?<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I have questions then:<br>
- what happens?<br>
</blockquote>
<br></span>
Debian has a release cycle of around 2 years. It uses three separate tracks: unstable, testing and stable.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Jessie is currently the stable Debian version, the current testing version is called stretch, and is about to enter in the freeze stage.<span class="gmail-m_4824271276728494462gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- what can be done to fix the situation?<br>
</blockquote>
<br></span>
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.<br>
<br>
Could you point out the issues that you consider critical in 2.8.5?<span class="gmail-m_4824271276728494462gmail-"><br>
<br></span></blockquote><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">​<br>Thanks for the explanation ​​Maximilian.<br><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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?<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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):<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><a href="https://www.calligra.org/news/calligra-2-8-6-released/" target="_blank">https://www.calligra.org/news/<wbr>calligra-2-8-6-released/</a><br><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">It's clear that Kexi, even if updated to 2.8.6 is more stable than 2.8.5, right?<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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.<br><br>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.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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.<br> </div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br>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 <a href="http://archive.org" target="_blank">archive.org</a> for a software. If that's the intent, fine with me.<br><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">If analogies have any purpose, let's use one. Apart of the FOSS factor, I can't see much of a difference between:<br><br>1. Offering the unsupported Windows XP version when shipping new PCs in 2016.<br><br>2. Offering the unsupported FOSS apps by Debian in 2016 with a "stable" sticker on <br>   -- 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.<br><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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. <br>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.<br><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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?<br><br>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?<br><br>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...<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_4824271276728494462gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- how to coordinate better?<br>
</blockquote>
<br></span>
There are two things that could be better improving coordination:<br>
<br>
- Notifying the package maintainers of critical issues that need to be fixed<br>
  in the stable release.<br>
  This could be done either through a bug or sending a private mail to the<br>
  uploaders (which sometimes is needed for certain security related issues)<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">Good, is email to <a href="mailto:kde-announce-apps@kde.org" target="_blank">kde-announce-apps@kde.org</a> enough?​</div> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- Coordinating on the version to release for the next stable release.<br>
  The current version for stretch is: 2.9.11<br>
  This could be changed if need so.<br>
<br>
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.<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">​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.<br><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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.<br><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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.<br>
<span class="gmail-m_4824271276728494462gmail-HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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.<br>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?<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"></div><br>-- <br><div class="gmail-m_4824271276728494462gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/<wbr>jstaniek</a></div>
</div></div>