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: Mon, 28 Nov 2005 17:10:11 +0100
User-agent: KMail/1.9

On Monday 28 November 2005 14:45, Andreas Tille wrote:
> 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.
I am unaware of where those shouls come from. Most of them are su busy with 
their own work they couldn't care less. After all getting the code to look at 
takes 10 minutes at most.
>
> >> 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.
We have developed a different view on that. There is no community hiding in 
the darkness waiting to come out. This has been researched and has been found 
to be true by many other FOSS projects. Don't take my word for it. Just read 
the studies if you should get bored one day.

> In German I would say: "Ihr schmort im eigenen Saft."
Means something like. "GNUmed developers are a secret community so outsiders 
cannot help even if they want to"
> 
> (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.
No so here as well as in most other vertical applications. It doesn't work for 
medical apps. It seems to work for window managers and apps that help 
developers develop. Just look at accounting apps on Linux. 

We suffer from one most stupid problem. *That* make people think gnumed sucks 
and is secret. We have noone consistently working on a webppage - the 
shopping window for any software. To make it even worse I have registered a 
bunch of domains myself which are so misleading that I am ashamed every time 
I think about it. You can have the most beautiful house (interior). Unless 
you have a decent looking front people will not even assume there is 
something to be gotten from GNUmed. How should they know about releases, 
documentation etc if we have half a dozen pages :-)

Everyone and their uncle talks about code. We need consistent PR work right on 
gnumed.org.
>
> > 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.
No doubt about that. I am tired of complaining. I just mention here that noone 
has even tried to work on making it more effient. No use in complaining about 
it. Just find someone to do 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.

Are we talking about the same group of IT-students ? The ones I know have had 
lectures on how to design a database theoretically or can tell you how to 
find and algorithm for finding black spots in a picture. They have no skill 
whatsoever when it comes to coding.
>
> > @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.
What can I say. Tell me or the portential coders a structure and you get it.
>
> 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.
Even too high level for my initial request. Where can I find  your work ? 
Where is the documetation on how to build Debian packages ?
>
> > 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.
Misconception. In priciple GNUmed ist ready. It just misses a bunch of 
features :-) Don't get upset. I am trying to get the messages across what 
level of detail is needed so someone can help effectively.
>
> > - 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.
I absolutely agree. Still those three are so different that we need to decide 
if we packaged them entirely separate or via some common build environment.
> 
> 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.
:-) You got it.
>
> > - come up with a way to find and include only those files that are
> > necessary for a release
>
> Interesting.
>
see above
> > - test your build scripts
>
> Yep - quality assurance.
yep. Just do it.
>
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]