Re: Upgrade inbox messages (was Re: [Gnumed-devel] No tabs at the bottom)

[Karsten Hilbert]

On Tue, Feb 02, 2010 at 01:05:19AM -0800, Jim Busser wrote:

> >> On 2010-01-29, at 12:37 AM, Karsten Hilbert wrote:
> >> 
> >>> Thanks. I notice one issue on that page: going to Manage
> >>> master data -> Workplace plugins and activating GNUmed
> >>> Default will NOT load that workplace on the next start. For
> >>> that to happen a config file needs to be edited.
> 
> So here's what I do not understand about the GNUmed packages...

There's one nitpick that we need to be aware of here: the
tarball is NOT a package. People running from tarballs need
to be aware of the fact that they are running from an
assembly targeted package maintainers rather than end users,
no matter how convenient we make it.

> from what you say, they provide a config file that is
> *full* of commented-out information, but provides
> *nothing* for
> 
>       [workplace]
>       name = GNUmed Default
> 
> why not provide the above?

Well, there was a lengthy thread about this last year
starting after people experiencing Gtk crashes (which will,
naturally, take down GNUmed without GNUmed being able to do
anything about it). The gist went something like this:

- If people did set up their own workplace they
  not be disturbed if at all possible.

- If people went with "GNUmed Default" they - by design - agreed
  to be at the whims of whatever GNUmed deems the default.

- However, let us use "Local Default" so even people with
  a modified "GNUmed Default" can be happy.

- There *should* be a default for when no workplace is
  specified at all

- That default better be fairly fail-safe even in the
  face of really adverse events (like Gtk crashes - which
  we cannot protect against but use as little as possible,
  e.g. with loading only one plugin).

- I seem to remember that we concluded that making it
  really obvious to users that setting up their workspace
  is a Good Thing(tm) would be beneficial. Which works
  nicely with the nearly-empty Local Default.

If we left the config setting at GNUmed Default I don't see
the point in having Local Default at all ?

Remember, we are talking about the tarball here, not about
end-user ready packages. A pristine tarball should (IMO) be
as robust as possible.

Package maintainers (Andreas, Sebastian) were notified
during release that they may want to re-default to "GNUmed
Default".

> Yes, I know it may be desirable that the installer /
> updaters do not overwrite what may be in a user's .gnumed
> directory (see footnote) however if somebody is *going* to
> copy in a .config file that is provided from a starter
> package may it not as well have a usable value than no value
> at all?

It does but the user must *activate* the value. If the value
was already activated in the system-wide config file why
copy over the file at all ?

If somebody is *going* to copy a .config file what purpose
would the copy have if not to adjust it ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346