Re: [Health-dev] Roadmap gnuhealth

[Mathias Behrle]

* Andreas Tille: " Re: [Health-dev] Roadmap gnuhealth (was: Force removal of
  gnuhealth* packages in sid?)" (Fri, 19 Sep 2014 15:58:00 +0200):

Hi Andreas,

> On Fri, Sep 19, 2014 at 01:14:11PM +0200, Emilien Klein wrote:
> > 
> > As indicated in my June post (first link above), the main reason for
> > this is the strict dependency of GNU Health on specific versions of
> > Tryton, and the incompatibilities in release schedules between the 2
> > projects, as you've mentioned in [0] yourself. A discussion with
> > upstream [1] to propose bringing the 2 release cycles closer didn't
> > improve the situation.
> > 
> > I've analyzed that before [2], most of the time the latest GNU Health
> > version doesn't run on the latest version of Tryton (but the version
> > prior to that). You can see the dates mentioned in the previous post,
> > the summarizing quote of which is "So looking at the 9 months between
> > 2013-04-22 and 2014-01-26, the latest version of GNU Health was
> > depending on the then last version of Tryton only for one month.".
> > 
> > [0]
> > http://lists.alioth.debian.org/pipermail/tryton-debian/2014-May/002303.html
> > [1] http://lists.gnu.org/archive/html/health-dev/2014-05/msg00015.html [2]
> > http://lists.gnu.org/archive/html/health-dev/2014-01/msg00042.html
> 
> I admit I personally dont have any idea about Tryton and GNUHeath so my
> point might be a bit naive.  I'd recommend watching the QA session with
> Linus at DebConf[1].  One major point he made is that you should never
> ever break an ABI.  So if Tryton is a system that breaks its interface
> so frequently that you always need to use the latest version my personal
> recommendation would be:  You should not use Tryton for business
> applications.  As I said I might be naive / uninformed but for me
> personally this means that I do not want to touch this system.

Since Tryton is a framework and we mainly are talking about the modules, we are
more on the API side.

The rules of the Tryton project say:
- Major releases are strictly API conservative, which means it won't be
  broken by bug fix releases.
- Also bug fix releases usually don't need a database upgrade.
- Between major releases API can change. This is considered necessary to not
  block or hinder the further development of the framework (and to not burden
  it with compatibility code being subject to make the code complicated,
  unreadable, less maintainable and more affectable by security issues).

So you are completely free to stick with one major Tryton version of your
choice, and for convenience we are providing the whole stack of supported Tryton
versions for Debian stable and testing. Just be aware, that Tryon upstream
provides bug fix releases for 2 years and you are done.
If OTOH it is a wise decision to stick with a version, where security and bug
fix support will be limited or no more guarantueed by the project is obviously
up to you.
 
> > Other reasons for not pushing harder on my side include:
> > - Upstream indicated [3] that they see not much benefit in having the
> > Debian package manage the database, but would rather want the Debian
> > package to just install the files, created the OS user (which runs
> > contradictory to your preference to run only one Tryton server under
> > the user provided by the tryton-server package) and install bashrc
> > files for that user, in effect mimicking the upstream-provided
> > installation script (motivation is uniformity in installation, user
> > under which the service runs, etc. over all installations of GNU
> > Health, regardless of the distribution on which it was installed)
> > - I don't see the benefit of providing a package which basically only
> > drops the source file on the disk, but for which the rest of the setup
> > needs to be done manually. I do understand this could be useful to
> > some users, and in fact the original form of the package provided that
> > (just respond "no" to the question if the database should be managed
> > by the installation process), but just uncompressing a tarball is not
> > what a Debian package should look like in my opinion.
> > 
> > [3] https://lists.debian.org/debian-med/2014/03/msg00208.html
> 
> Since I had a similar discussion with the GNUmed authors where I had the
> same packagers attitude as you Emilien and the GNUmed authors followed
> the same idea as GNUHealth authors I think there must be something
> behind it.  I actually realised that in the end it is way less work for
> me as a packager to follow their opinion which was reason enough to me
> to spend my time on other projects.  So while not beeing finally
> convinced that they are right it is implemented according to their
> recommendation anyway. :-)
> 
> > That being said, looking at the number of posts in the past months on
> > the project's lists of users that have installed the software, but
> > can't make connection to the server, I remain convinced of the utility
> > of a package in Debian and derivative distributions that allow a user
> > to just install both server and client side with one command (`apt-get
> > install gnuhealth` and run the client `gnuhealth`) remains valuable,
> > definitely for people trying the software out. That's the first step
> > in making the software known, a new user can try it out rather simply.
> > Of course when you're satisfied and want to run it in PRD, you'll have
> > to think better on your deployment and backup strategy. But there's no
> > harm in e.g. having the package take an extra automatic backup of your
> > database ;)
> 
> +1
>  
> > I meant inclusion in the Tryton Debian archive. Similar to what you've
> > just indicated [4].
> 
> What exactly is "the Tryton Debian archive".

Just have a look at [1][2][3], I hope this answers your question.

> Mathias wrote about
> "something outside main" which I actually would call a restriction I
> would not like since you will miss all the QA stuff which makes a
> package for science and business applications really valuable.  Debian
> is nit just a bunch if simple to install software but a distribution of
> *tested* software that fits *together* properly.

It is currently just not possible to maintain this package sets within Debian.
Perhaps it will be, when we have something similar to PPAs.
On one hand you claim API stability (which is provided by means of
debian.tryton.org), on the other hand you claim Debian infrastructure. Both are
not possible. I think, for the time being it is the best trade-off to have the
current stable release in Debian unstable/testing and to provide up-to-date
packages for former releases by debian.tryton.org.

> > I hope you don't get a negative feeling on my part from this message.
> > I am still as enthusiastic about Debian [Med] and GNU Health, but I've
> > come to realize that packaging in the official Debian repository
> > currently has challenges, and that I feel my contributions can be more
> > impactful on other aspects ;)
> 
> Finally you are a volunteer and you are free to decide how you will
> spent your time.  I do evaluate your past work really high and I'm sure
> your future contribution will be as well (whether inside Debian or
> outside).
>  
> Kind regards and thanks for your explanation
> 
>      Andreas.
> 
> 
> [1]
> http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/QA_with_Linus_Torvalds.webm
> 

[1] http://tryton.alioth.debian.org/
[1] http://tryton.alioth.debian.org/mirror.html#why-debian-tryton-org
[3] http://debian.tryton.org/debian/dists/


-- 

    Mathias Behrle
    MBSolutions
    Gilgenmatten 10 A
    D-79114 Freiburg

    Tel: +49(761)471023
    Fax: +49(761)4770816
    http://m9s.biz
    UStIdNr: DE 142009020
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

signature.asc
Description: PGP signature