[Gnumed-devel] Re: get something done

[Andreas Tille]

On Sun, 27 Nov 2005, Sebastian Hilbert wrote:

> 1.) good quality assurance to code
> - how, what
> 2.) and database might be
> - how , what

Well, my experience tells me: Just let a computer scientist / database 
professional
have a look at your code and wait one hour.  He will tell you how and what.

> > very valuable.
> indeed but that is to big a bite. You have to break it down even more.
> Pointers to docu, expectations ...

Performance, usability, coding style, etc.
The problem is that the number of people who are involved in GNUmed is currently
to low to let the OS principle of many eyes looking at the code starts working.
In German I would say: "Ihr schmort im eigenen Saft." (sorry for the non German
speakers - I have no useful translation for this).  I have observed it in other
projects that exactly the task I formulated intentionally vague leaded to a
spin off.

> 3.) Performance checks regarding the use of external database
> - pointers to documentation, what exactly is it you want to get checked, how
> fine grained, by what means , what are your expectations

My expectation would be that the access via DSL connection would be reasonable
fast.  I'm not sure whether this would be a real use case but would argue that
*if* it works via DSL it will be performant enough for all other use cases.

> > seems to be necessary (reducing database requests),
> that is about the level of detail I expect

Sure - this was the only part of GNUmed I dived deep enough into it to specify
a problem detailed enough.

> 4.) enhancing usability of the plugins
> - (in dependance whether they are called independently or from GNUmed),

For instance if you call plugins independently from GNUmed (for instance
the BMI plugin) you often miss a method to quit this program cleanly.

> - more pointers needed as to what plugin system, where is the code , why both
> methods

I don't know the plugin system but I'm definitely sure that any plugin
system is a complicated piece of software and independant people with
experiences in this field should have a close look at it.

> Remember. Those people have never seen GNUmed before. They don't know much
> about coding

Ups, than I was thinking about a different type of people.  My remarks were
targeting at high level informatics students doing some practical work for their
exams or something like that.  IMHO the GNUmed project needs definitely
expertise from computer scientists.

> @Andreas
> You might want to consider spelling out the problems with packaging.

There are no basic problems with the client.  Something I would change
a little bit at the GNUmed distribution side is that you arranged: You
try to duplicate the target installation tree which I would just call
unusual.  Perhaps the source traball should be a little bit more flat.

Regarding the server it is mostly just a lack of time.  If there is somebody
who wants to support me - everybody with some basic Debian packaging
knowledge is welcome.

> evaluate, test and enhance a cross platform or multi platform packaging
> strategy

Well, I do not know anything about other platforms but I guess if the thing
is solved in principle for one platform others will be no real problem.

> - write up a short paper on why a single way to package fits or doesn't fit
> all OS

But please keep the following thing in mind: We can not spend much man power
into systems which will be used by less than 10 users.  The relation of man 
power
and effort to the needed comfort has to be reasonable.  IMHO it should be not
a primary goal of GNUmed to be available on as much as possible plattforms.
I think Linux, Mac OSX and Win should be covered.  Leave the effort to adapt
the installation to the developers of interested distributions (as you did it
for Debian - it is just my fault / decision to maintain a stronger contact to
you).  There are conversion tools like alien and I even heard that latest SuSE
can install Debian packages.  So keep the effort for this low compared to the
real development.

> - come up with a way to find and include only those files that are necessary
> for a release

Interesting.

> - test your build scripts

Yep - quality assurance.

...

Kind regards

           Andreas.

--
http://fam-tille.de