[Gnumed-devel] Re: Choice of programming language and project management

[Gour]

>>>>> "Andreas" == Andreas Tille <address@hidden> writes:

Andreas> In short: I regard Python as a good choice for GNUmed.

I agree with it as well.

Andreas> I have a not so good feeling about the ability of the GNUmed
Andreas> project to gather fresh blood.  

[...]

Andreas> Just ask try to answer the question: "How many key people in
Andreas> our project can be hit by a bus before our project dies."  If
Andreas> the answer is <=2 you will have a problem sooner or later.

I already put too much ink here about some issues, but yesterday I had
some some realization while trying to package GNUmed for ArchLinux...

Without a doubt, the package which I put together for GNUmed server was
the most dumb I ever wrote...I reserve the right that it is not so
stupid to provide package for Debian (which I used as reference), but
mostly package scripts (called PKGBUILD) for Arch are quite simple and
they reflect manual steps one would do when installing from the tarball.

Here is the part of the pkgbuild for GNUmed-server:


build() {
    cd $startdir/src/GNUmed-v$pkgver/server
    
    # conf stuff
    mkdir -p $pkgdir/etc/gnumed 
    cp etc/gnumed/* $pkgdir/etc/gnumed/ || return 1

    mkdir -p $pkgdir/usr/sbin
    install -m 755 gm-* $pkgdir/usr/sbin || return 1

    mkdir -p $pkgdir/var/lib/gnumed/server
    install -D -m 644  __init__.py $pkgdir/var/lib/gnumed/server || return 1
    mkdir -p $pkgdir/var/lib/gnumed/server/bootstrap
    cp bootstrap/* $pkgdir/var/lib/gnumed/server/bootstrap || return 1

    ...
}

and it consist of cp-ing stuff into appropriate locations.

I did the gnumed-server script, but did not have nerves to continue with
the client part.

What I wanted to express here is the lack of some standardized setup
procedure to build the package, making it unnecessarily hard for
distro-packagers.


Some points:

a) tarball is named GNUmed-server.v11.0.tgz using not so common *.tgz
suffix (tar.gz is more standard one) and why is there v11.0 in the name
instead of more standard GNUmed-server-11.0.tar.gz?

b) name of the package is not consistent with the content, i.e. when one
opens the tarball there is no GNUmed-server.v11.0 folder, but
GNUmed-v11.0 :-(

c) man pages have to be manually gzipped and copied, localization pages
are all in one folder...


Incidentally, in a recent time I became aware of OpenERP and Medical (
http://medical.sourceforge.net/) after which I became interested in
Tryton (http://www.tryton.org/) for which I was able to quickly put
together packages for the server, client and bunch of modules 'cause all
the packages use standard Pythonic way via: python setup.py install and
one can clearly read setup.py to find out about all the dependencies as
well as optional stuff.

Although OpenERP is (sometimes) breaking their API, Tryton has very nice
policy in regard to the release process - see 

http://code.google.com/p/tryton/wiki/ReleaseGeneral

and it is very easy to find out which server is required for certain
version of the client & modules, e.g. for any tryton-server-1.2.x
release, one can use any tryton-client from 1.2.x series, same with
modules. (Same with OpenERP)

Despite of what is said here, having server-v11 for client 0.5.x just
creates confusion.

So, although GNUmed is written in Python, I do not understand why there
is no installation procedure to make it easier considering there are
similar client-server apps who follow this path and (easy) deploying of
application is a good way to bring fresh blood to the project.

Use of CVS is not critical, but these days one is expected to be more
'modern' :-)

As far as I'm concerned, I'll either try to port Medical (btw, it's
project of the month - http://sourceforge.net/community/potm-200909/) to
the Tryton or customize some of the present Tryton modules and write the
rest - it's the platform which requires less work than fiddling with
wxpython.

At the end, let me say that, despite of expressing some criticism here ,
I very much admire work of GNUmed devs, especially of Karsten who almost
single-handedly pushes the project forwards, but, as Andreas pointed
out, maybe the project requires some shift in its orientation in order
not to stay in the niche and brings new people in.


Sincerely,
Gour

-- 

Gour | Hlapičina, Croatia  | GPG key: F96FF5F6 
---------------------------------------------------------------------------

pgp04LhyBJn6C.pgp
Description: PGP signature