One point I'd like underline explicitly is: let us stay away from the management of an actual server if we can. All the discussions so far seem to imply this, but I wanted to express this clearly. Regardless of what we choose, if we can avoid having an actual machine to take care of, we'll do much better. It does not matter if it is a virtual or real machine, there will have to be security updates, software updates etc. It is much more efficient to consider this aspect of running the tools as infrastructure and delegate it to whatever provider we use. Unless someone thinks we need to have full control of a server, let us go with a set of services, and leave the management of server to hosting provider.
I think we need to distinguish between collaborative tools for wiki, CKM, web site, SVN etc and development infrastructure. Build servers, or a server for some web services should not be handled on the same infrastructure with the collaborative tools. I think that is a different discussion. Kind regards Seref On Mon, Sep 19, 2011 at 9:09 AM, Erik Sundvall <erik.sundvall at liu.se> wrote: > Hi! > > On Sat, Sep 17, 2011 at 00:10, Bert Verhees <bert.verhees at rosa.nl> wrote: >> The main reason is, the Linux Kernel development must not be >> depending on a single person or company. That is too dangerous. > > I think this "dependency" is one of the key things to consider > regarding openEHR too. > > When it comes to version control of software I don't think it it would > be a _huge_ problem if we used a free commercial solution in the > cloud. If they start giving us trouble we simply move the code > elsewhere. It's still a problem though since we might lose the old > versioning history of the project. Tagged releases could be kept as > zip-files of course, but the continuous history is lost. Git is > different, everybody that wants it can have the complete digitally > signed tamper-proof versioning history. There is technically no single > central point of of control in GIT (even though you can socially set > up your project to work in a centralized manner regarding release > related branches etc if you wish). Thus if we use a commercial Git > provider like Github we could move elsewhere without losing versioning > history. > > But again, regarding software up to now we have not had many > independent branches and most important design discussion and > announcements are facilitated out-of band in mailinglists rather than > via the versioning control comments etc so losing version history > might not be too disastrous. > > Regarding archetypes on the other hand most discussion is nowadays > done in the combined CKM versioning & discussion tool, so losing > history from that combined repository would be a very bad thing. So if > we would be using a version control system as underpinning for a > future CKM alternative or for some kind of archetype "nursery", then I > think Git would be the very best way to go. Everybody that wanted a > copy could of the complete history could have one and you could in a > controlled manner at the same time follow and reintegrate development > work from local/national efforts etc. If we at the same time could > integrate the technical backend of the clinical > discussion/communication regarding the archetype development too it > would be great. (That does not mean that clinicians would be forced to > understand GIT - a clinical frontend GUI could be similar to the CKM > or whatever.) > > So some suggestions: > - Let each software project pick their own versioning mechanism, but > perhaps try to agree on hosts, e.g. use cloud-service X for SVN and > cloud-service Y for GIT so that developers involved in several openEHR > projects don't need to register accounts in too many places > - If any future functionality (like CKM++) is BASED ON a versioning > control system (rather than just using one) then make sure it is open > source and that complete history is not only kept at a single point. > Git would seem to be the obvious choice here. > - If a unified issue-tracker service could be used for all projects > then that would be preferrable. Also here it is important to use an > open or decentralized system so that the issue tracking history does > not get lost if a commercial service changes terms or goes bankrupt. > - Regarding dependency and vulnerability I also think it's important > that (as in the Apache organization) every openEHR board and > sub-project has members or "committers" from at least three different > economically independent organisations. > > Best regards, > Erik Sundvall > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
