[Debian-med-packaging] gnuhealth in testing blocking new Tryton series

Mon May 5 14:07:27 UTC 2014

Hi Mathias and all,

2014-05-05 14:27 GMT+02:00 Mathias Behrle <mathiasb at m9s.biz>:
> * Emilien Klein: " Re: gnuhealth in testing blocking new Tryton series" (Sun, 4
>   May 2014 23:07:15 +0200):
>
> Hi Emilien,
>
>> 2014-05-01 14:06 GMT+02:00 Mathias Behrle <mathiasb at m9s.biz>:
>> > AFAICS the gnuhealth project just released version 2.4.1 with an update for
>> > the 3.0 series [3], but I couldn't detect a message or roadmap for the
>> > migration to 3.2.
>>
>> The version 2.4.1 of GNU Health is the one currently packaged in
>> Debian {unstable|testing}. It indeed depends on Tryton 3.0, and is not
>> supported to be run under Tryton 3.2.
>
> Yes, of course. Although there were really few API changes (1) from 3.0 to 3.2
> and it could be, that gnuhealth could just run without any changes on 3.2, I
> agree to not do so or even publish, if you are not very familiar with Tryton.

We are in agreement, it might technically be possible but it is not
sound to do. Things might break in unexpected ways, and neither Tryton
nor GNU Health developers would be able to help.

>> The next release of GNU Health will be able to run on Tryton 3.2. I
>> have reached out [4] to the GNU Health development team to enquire
>> what the expected release date for that new version will be. I expect
>> it to come in the next ~2 months.
>
> Thanks for your initiative.

As responded [7] by Luis (main GNU Health developer) GNU Health 2.6
will be out July 6th. This version will be Tryton 3.2 compatible.

>> > Since the migration of gnuhealth to the current Tryton series doesn't seem
>> > to be imminent, it seems to be the appropriate way to remove gnuhealth from
>> > testing. AFAIS this should be done by the maintainer filing the bug for
>> > release.debian.org at packages.debian.org (correct me, if I am wrong).
>>
>> The goal of the Debian project as a whole is to release the *stable*
>> distribution (roughly every 2-3 years, but in practice "whenever it's
>> ready").
>> In any case, the freeze for the next stable version is in roughly 6
>> months: the 5th of November 2014 [5].
>>
>> I see no reason in this case for removal of a functioning package from
>> the Debian archive.
>> We could start discussing versioned packages, but I have to admit I'm
>> not a fan of this approach unless absolutely necessary.
>>
>> A few months back I started a discussion with the GNU Health
>> development community to figure if the dependency was really that
>> strict. The answer was yes [6].
>
> As stated above I agree on the hard dependency of gnuhealth modules versus
> Tryton series (as for each other Tryton module).
>
>> > So I want to ask you to file the removal bug for testing or to agree, that I
>> > can file it.
>>
>> To summarize and be explicit: I do not plan to file a removal request,
>> nor agree to you filing it.
>> The newer GNU Health version should be released in time for it to be
>> packaged for Debian before the Jessie Freeze.
>> And in any case, both Tryton 3.0 and GNU health 2.4 are versions that
>> are currently still supported by their upstream, so there's no reason
>> to remove any of those from the testing distribution. It is part of
>> our Debian maintainship to support those packages (e.g. by backporting
>> security patches if needed) to the best of our extent.
>
> So you hit the point, but it seems perhaps not in its whole consequence. There
> are several aspects to be weighted.
>
> Let's talk about
>
> * duration of series support
> * security releases
> * bugfix releases
>
> Duration of series support
> --------------------------
>
> This time range is defined for Tryton releases to be 2 years. So you can easliy
> see, that we must be interested to get the really last possible Tryton release
> into Debian to not ship a completely outdated and finally relative
> shortly supported version with respect to the Debian release.

By including a piece of software in the Debian archive, you commit to
supporting it for the duration of the Debian release's support
timelines.
Example scenario (Assuming 2 Tryton releases per year)
- If the current Debian release is 1.7 years old, assuming that the
freeze period lasted for 10 months, you likely have a Tryton version
in the stable Debian release that is not supported by Tryton itself,
since that version is already 2.5 years old.
- If a security vulnerability is found in Tryton, affecting all Tryton
releases (the newest version, the other 3 supported versions, the
version in Debian stable and possibly older unsupported Tryton
versions), even though Tryton won't release a fix for the version in
the Debian archive, it would be your responsibility to review the
patches to the supported Tryton versions and "backport" that fix to
the version in Debian.
The fact that the release in Debian isn't supported by upstream
anymore is not a sufficient reason to not fix the security issue.

The real criteria is thus the duration of support of a Debian release,
and the Debian developer community owe to their users to continue
maintaining software that is possibly unsupported by their original
upstream.

> BTW: Are there any statements of the gnuhealth project about maintenance cycles?

The wiki [8] mentions "Since version 2.2.1, "patchsets" will be
released for the GNU Health stable versions (those with even minor
number, ej 1.2.3 )". It is not mentioned for how long the "stable
versionS" are supported. Will ask upstream for clarification.

> Security releases
> -----------------
>
> Security fixes will always be accepted into Debian for the different
> distributions.
>
> Bugfix releases
> ---------------
>
> The bugfix releases published by the Tryton project more or less monthly mostly
> never reach the severity of RC-bugs, which means: you get them into Debian
> before the freeze and perhaps with great effort shortly after.

If bugfix releases are made for the version that is in the current
stable Debian release, it would make sense to make the Debian users
benefit from those.
What's generally not allowed is to upload a new version (including all
kinds of new features, etc.) to a stable Debian version (to minimize
the risk of breaking a user's system), but uploading bugfixes is more
than recommended.
Since you've got your entire packaging history in a VCS, it would be
fairly straightforward to branch the packaging and create a new
release with the bugfix, while a newer version is already uploaded to
unstable/testing.

> To summarize:
> The interest to get a mostly bugfree release into Debian is contradictory to
> its maintenance duration.

Depends on how you look at it. The fact that a version becomes
unsupported by its upstream doesn't make it less stable. It's just
that they won't publish a fix for that version, if it is encountered
in a more recent version. And that's where our Debian maintainership
role comes into play, to backport fixes (due to the complexity
involved, this is naturally only done for security issues, not
"classic bugfixes", although nothing prevents you from backporting a
bugfix if it provides enough benefit to your users)

> Lets look again at the dates:
>
> Tryton version 3.4 is due to be released around 21.10.2014.

Yep, 15 days before the freeze.

> With respect to the Debian freeze this would mean: it could go in and probably
> 1, at most 2 bugfix releases. The probability to have stable and well tested
> Tryton releases from the beginning is increasing, since the great
> reorganisations of the framework (compared to its original fork from TinyERP
> 4.1) are done. So also the probability is high, that it would be preferable to
> have 3.4 in Debian containing also such heavily requested features as the web
> client, which I assume to be released for 3.4.
>
> Now there is indeed the problem with gnuhealth lagging behind the Tryton
> releases about three months. I think you understand, that I am
> not pleased by the fact, that gnuhealth will block the Tryton packages and
> forcing Tryton packages to be even more outdated than they will be anyway by
> the time of the release...

I do understand, and share your opinion. Please be assured that having
GNU Health blocking useful updates to users of Tryton is not something
that makes me happy.

> Would it be a perspective to talk to the gnuhealth devs to stick closer to the
> Tryton releases (perhaps at least for the Tryton release 3.4 in October)?

Definitely. I will start a new conversation, asking for how long
releases are supported, and if they would be able to align more
closely with the Tryton releases.
Although I'm not sure they would be able to release within 15 days of
Tryton's 3.4 release, which (unless we get a freeze excpetion for GNU
Health) would still mean Tryton 3.4 blocked from entering Testing
before the freeze.

>
> @Raphael:
> I would be happy to hear your opinion, if this problem is enough to justify the
> overhead of versioned Tryton suites like tryton-server-3.2, tryton-server-3.4
> to avoid blocking a dependent project the main project?

Due to the large number of source packages (78 if I counted well),
should this be discussed with the Release team as well?

>> I appreciate your patience, and will make sure to package the newest
>> GNU Health version as soon as it is made available.
>>     +Emilien
>> [4] http://lists.gnu.org/archive/html/health-dev/2014-05/msg00006.html
>> [5] https://lists.debian.org/debian-devel-announce/2013/10/msg00004.html
>> [6] http://lists.gnu.org/archive/html/health-dev/2014-02/msg00019.html
>
> (1) http://code.google.com/p/tryton/wiki/Migration_3_2
>

   +Emilien

[7] http://lists.gnu.org/archive/html/health-dev/2014-05/msg00008.html
[8] http://en.wikibooks.org/wiki/GNU_Health/Patches_and_Patchsets