Re: [Gnumed-devel] Re: GNUmed & blueprints

[Karsten Hilbert]

> > The rationale would be different priority: when user finds a bug in  
> > production version, it should be fixed ASAP
I agree.

> As soon as people upgrade to a high enough version of the client, it  
> will be more possible for them to know the availability of update /  
> patches, which will help. In fact, I even think that the client's bug  
> handler should, on exit, call the update window, either  
> unintelligently (whether or not there is an update) or intelligently  
> (only if there is an update).

Well, there's at least two things to consider with this:

a) People cannot always easily upgrade even when there's a new version
    available by the GNUmed team -- they will have to wait until a proper
    package is readied for their distribution. They *can* run a tarball
    locally but many people will not want that.

b) We should limit ourselves as to what we do inside the exception handler.
    There is no known application state at that point.
    However, I will make the exception handler at least display if
    there is a newer client version available.

> For bugs being reported by people who are actually using it in  
> production, I almost think it is worth having a way to identify and  
> funnel specially those bugs.

I tend to agree. However it is a bit hard to be fair here. Currently we still 
know
who is in production and who isn't. Should that happen to get out of bounds I 
do believe there's a business model to be had.

Karsten
-- 
Psssst! Schon das coole Video vom GMX MultiMessenger gesehen?
Der Eine für Alle: http://www.gmx.net/de/go/messenger03