Re: [Gnumed-devel] restrictions vs. conventions (uncertain date-time)

[Busser, Jim]

On 2013-08-24, at 2:54 AM, Jerzy Luszawski <address@hidden> wrote:

> Jim - you elaborated a lot of detailed descriptions of required changes
> - it seems to me that you could just implement these changes by yourself :)
> 
> But the main thought I would like to share is, that besides hard-coded
> requirements required to maintain the sanity of database …

> 1. if the date is less than DOB - the date is totally unknown (=DOB is
> not a good idea, as it could be exact date)

The suggestion for clin_when less than DOB only works if the hard-coded 
requirements remain sufficiently unconstrained to permit such values.

For example, if a trigger is defined to disallow a clin_when < DOB – and which 
could easily be conceived and implemented – then such flexible use becomes 
impossible, at least within GNUmed main.

Coming back to Jerzy's offered alternative, which is to just implement these 
changes by oneself …

This would have the big advantage of individualization and a number of 
disadvantages, including

- labour-intensivess
- less testing and therefore risk of bugs, and
- the opportunity costs of spreading more-thinly what limited coding talent 
does exist.

Would the 'thing' that one would implement by oneself be a fork?

Assuming that I would not want to evolve 'away' from "GNUmed main" any more 
than necessary, then some way to track along side it would seem necessary for 
sanity.

I would imagine that starting with "GNUmed main" and then identifying the 
things desired to customize and making those changes,
and then experiencing all unwanted side effects, and then fixing those 
side-effects, is fine until wanting to enjoy something new available in "GNUmed 
main".

Are the two basic approaches to doing this

(1) taking "the new GNUmed release" and re-applying -- to the extent that one 
can -- all of one's own patches and detecting and fixing new incompatibilities 
with new local patches, or alternatively

(2) taking one's "fork", and then applying to it all the patches which had in 
the meantime been applied to "GNUmed main" in order for it to become "new 
GNUmed release"

and where maintaining (2) is more complex and requires a higher level of skills 
to keep working than (1)?

-- JIm