Re: OSCAR 10.12 has been packaged
Thank you for your kind words and encouragement
Our source is in GIT and we reveal the source of our trunk stable (not
really but not badly unstable) and releases on Sourceforge
(we use a different repository for submission and vetting of code)
I have not packaged the source, and would have to look up the meaning
and content of the files you speak of in
but really I am not ready
I am a country doctor who does this in his "spare" time
there is no one else interested in doing the work (for the reasons implicit)
As mentioned I am preparing to package our next release which will be
alpha in just a few days
AND
Equally importantly the project isn't grown up enough (or has grown up
without thinking about these things until recently)
Among other faults, to my understanding a unforgivable sin for your
purposes, is that we have a number of jars that we do not reference
from the source but provide with unknown or forgotten lineage (I would
have to check with the programmers, the number has dropping
dramatically from over a 100 but was not 0 at the last reckoning)
================
Peter Hutten-Czapski
Haileybury Ontario
"The attitude that ‘if rural people want these services they’ll have
to come to the city to get them’ is simply not acceptable…” (Newbery,
1999)
Before printing, think about the environment. Avant d' imprimer,
pensez à l'environnement.
On 30 July 2012 03:55, Andreas Tille <andreas@an3as.eu> wrote:
> 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
>
Reply to: