gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Re: get something done


From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] Re: get something done
Date: Sun, 27 Nov 2005 20:00:14 +0100
User-agent: KMail/1.9

On Sunday 27 November 2005 19:26, Andreas Tille wrote:
> On Sat, 26 Nov 2005, Sebastian Hilbert wrote:
> > What do you have to do ?
> > 1.) write a project description (200) words what you want to get done
>
> If you ask me a 

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

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

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

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

4.) enhancing usability of the plugins 
- (in dependance whether they are called independently or from GNUmed), 
- more pointers needed as to what plugin system, where is the code , why both 
methods 

Remember. Those people have never seen GNUmed before. They don't know much 
about coding and the certainly don't have time to figure out everything 
without pointers

5.)general investigation in the plugin system.
- way too general :-)
- what do you want them to inverstigate ? Alternatives ? Enhancements ?
>

Thanks for providing a basis for discussion. You see even with potential 
ressources at hand it is a bunch of work for the individual subproject 
manager.

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

e.g. 6.)

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

- are there any "build environments" or build tools that can be used on many 
OS and platforms
- if not is there a way to build a common base for different packages and OS 
distributions ?
        - base might be tgz which is packaged on GNU/Linux
        - other OS might unpack and package from that
        - come up with scripts to build a build environment
        - implement as many OS as you see fit
- write up a short paper on why a single way to package fits or doesn't fit 
all OS
- come up with a way to find and include only those files that are necessary 
for a release
- test your build scripts
- document your scripts in the code itself
- produce documentation with apidox or other tools as you see fits
pointers : py2exe, packaging in Wiki, Debian package management, Rdehat 
package management
links: http://www-uxsup.csx.cam.ac.uk/courses/rpmbuild/, many more

Sebastian
-- 
Sebastian Hilbert 
Leipzig / Germany
[www.openmed.org]  -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86   -> No files, no URL's
VoIP: callto://address@hidden
My OS: Suse Linux. Geek by Nature, Linux by Choice




reply via email to

[Prev in Thread] Current Thread [Next in Thread]