Hi Thomas Beale, Our, Ruby implementation repository has already moved on GitHub for our convenience last year for our convenience. I was wondering if we could move our repository under github://openehr/ruby-impl-openhr. It would be comprehensive rather than under skoba/ruby-impl-openehr for publicity.
Regards, Shinji Kobayashi 2012/5/7 Thomas Beale <thomas.beale at oceaninformatics.com>: > > yes, we will obviously migrate over to Github in the coming months. I have a > slight concern about how to avoid chaos, and I do think we need to think > carefully about how we organise Git projects/subprojects in general. The > openEHR terminology is not large (at all), but looks like it will become > more than one file, according to a discussion the other day (I will write > this up and post it before doing anything), but I was thinking it needs to > be part of a broader openEHR knowledge repository. Although... I have listed > it as a distinct 'component' of the specification program - maybe it should > have its own repository anyway. Translations of it will multiply the number > of files substantially as time goes on, so that is another reason perhaps > for a separate repository. > > I think test archetypes & templates probably should be separate from test & > example data, so that is two repositories right there. That would give us: > > open terminology > test archetypes & templates > test & example data > > We need to add existing active software projects: > > Java ref implem project > ADL Workbench > (Ocean) Archetype Editor > Opereffa > > Not sure about the following: > > LiU modelling tools > > Ruby I think is on its own repository; the Python implementation I believe > is no longer openEHR, but some kind of custom fork in its own repositories. > openEHR on .Net is on codeplex. > > Any others? > > - thomas > > > On 07/05/2012 10:55, Erik Sundvall wrote: > > Hi Tom! > > Could we use the openEHR github project (that you registered) for > hosting a subproject with the openEHR Terminology? I believe it can > make ongoing branching/patching more visible and easier to > merge/administrate. > > There is no hurry to move existing test-archetypes there, but for new > efforts (terminology, RM-instance-examples etc) me might as well start > there (perhaps as a separate subproject). > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
