Hi Peter,
On Sun, Jul 29, 2012 at 09:24:24AM -0400, Peter Hutten-Czapski wrote:
> ...
> The vast majority of end users have someone that they depend on to
> install and maintain Oscar (in our parlance Oscar Service Providers).
That's an interesting bit. May be you are interested in my recent talk
at Libre Software Meeting in Geneva:
http://people.debian.org/~tille/talks/20120711_vista-in-debian
which is also available as video recording
http://video.rmll.info/videos/integration-of-vista-into-debian/
and you might specifically interested in slide 26 / 29 (and this
specific slide gained also some interest in the article from European
Commission "Joinup" (which is linked at the bottom of the first link).
> The OSP's in a way are our chief "customer" and do not need a deb as
> they can follow our instructions for compiling from source, and/or
> make their own deployment scripts.
Having a Debian package is not about the ability to follow installation
instructions but rather to effectively roll-out a system effectively.
While it is perfectly true that specifically due Ubuntu nowadays you can
find software on some private computers at home of people who where not
able to install this set of software otherwise this is not the only
usage of Debian packages.
I have no idea what those deployment scripts you are mentioning above
are doing and of which nature these might be but to some extend the
wording smells like some custom solution of issues which were also
solved inside Debian packaging techniques. If the OSP's (which I
personally consider the main target audience of Debian Med if it comes
to medical record applications) would consider implementing their
deployment scripts as Debian packages I would see some potential to save
time in the long run.
> McMaster University actually has a
> course and auditing standards for OSP's to ensure deployments are
> secure and functional which a deb cannot do.
Your way of quality control is somehow orthogonal what Debian might
provide. We surely can not run extensive tests in practice (even if
running a technical test suite is part of the build process). The
quality is rather on a technical level to verify the compatibility with
other components of the system, there are automatic build which
guarantee that the software builds without problems etc. And finally
you might have some additional eyeballs looking at the source from
a different angle which sometimes is a good thing to have.
> So for the moment and the near future our poor man's debification of
> Oscar will have to do. I am interested in getting it cleaned up so
> that it would be eligible to enter a repository, its just too much for
> me right now.
I do not think that you are really bound to what you call "poor man's
debification". It depends from your estimation whether the advantages I
mentioned above are worth spending some extra time into it - depending
from the current status (which I could estimate if you would provide the
source package I was asking in my previous mail) it might be not that
much. My suggestion would be to inject your current packaging stuff
into our package development platform alioth.debian.org in the Debian
Med area. This process is described in the Debian Med policy
document[1] and I'd volunteer to do this technical process as some kind
of kick off. Considering that you mentioned Git in the beginning of
your other mail I assume that you will prefer Git over SVN.
In short: If you unreveal the source of your Debian packaging I would
inject it into our packaging VCS and will see whether I could do some
simple enhancements. You can perfectly keep on releasing "poor man's
packages" but you can base it as a first step on the status of this
VCS which is group maintained by the Debian Med team.
Kind regards
Andreas.
[1] debian-med.alioth.debian.org/docs/policy.html
--
http://fam-tille.de