[tryton-debian] gnuhealth in testing blocking new Tryton series

Mon May 5 12:27:06 UTC 2014

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

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

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

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

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.

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

Lets look again at the dates:

Tryton version 3.4 is due to be released around 21.10.2014.
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...

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

@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?

> 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

Thanks and cheers,
Mathias

-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/tryton-debian/attachments/20140505/07c5af30/attachment.sig>