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
