Moving Custom Messages Module sources to Git

[Mykola Vorobey]

Hi,

Actually, the huge part of work on implementing of In-Page Localization Project will be done as enhancement of Custom Messages Module. In order to preparations to start coding on this project, during the last couple of days, I was working on mavenization of custommessages trunk. At the moment, module source code is already moved onto maven platform. As another important enhancement, that we would like to introduce for custommessages module, will be moving of it's sources from Subversion to Git. Before we actually did it, we would not mind to know your position about such kind transformation. May be, is there anyone who has comments about moving this module from Subversion to Git or has strong arguments why we should not do it now. Please, share your feedback here.

Best,

Mykola

[Darius Jazayeri]

See the "Migrating to Git" wiki page at https://wiki.openmrs.org/x/ooqmAQ

I love git, and I'm happy to see any module move to it.

I think we were still discussing whether we want to put all modules in github.com/OpenMRS, or reserve that for "officially supported" modules. (I thought we were going to do the latter. I think Burke want to put everything there.)

-Darius

-- OpenMRS Developers: http://go.openmrs.org/dev
Post: d...@openmrs.org
Unsubscribe: dev+uns...@openmrs.org

[Friedman, Roger (CDC/CGH/DGHA) (CTR)]

I have no objection to all of OpenMRS moving to git in the future, it seems to be the direction in which people want to move.  Nor do I want to interfere with peoples' desire to work on their own git sites.  However, I don't think that work done on git should "count" until it's in svn.  That is, no changing ticket status, no GSOC credit, no code reviews, no putting in OpenMRS module  or maven repo until it is in svn.  If we can modify our Atlassian setup to be version-control-neutral and work with the OpenMRS git repo, and get the procedures in place to assign appropriate rights to parts of the OpenMRS git repo, that would be a good first step toward all of OpenMRS moving to git, and at that point we could work in either (although still putting code into svn at key points in the dev process).  The common codebase is one thing that keeps the community open and enables us to share work, as soon as development starts being done on private sites, we lose that.  We've worked before with people who used their own organizations' svn sites and ticketing, but again that work wasn't considered OpenMRS work until it appeared on the OpenMRS svn repo.

-- OpenMRS Developers: http://go.openmrs.org/dev
Post: d...@openmrs.org
Unsubscribe: dev+uns...@openmrs.org

[Burke Mamlin]

Actually, I don't necessarily want to put everything into the github.com/openmrs organization.  The advantages of putting repos under the OpenMRS organization are (1) centralizing user access and (2) making it easy to find the source code.

In the long run I don't believe that we want to depend on the OpenMRS organization in github for finding source code; rather, my hope is that we'll turn our efforts on making it easier to find source code wherever it is – e.g., improve our module repository and find a way (via naming conventions, README conventions, etc.) to locate source that has not been published to the module repository.  In short, aim toward an approach that still makes it easy to find source code of interest when there are 3000+ OpenMRS-related repos around.

-Burke

[Michael Downey]

Hi there,

On Wed, May 23, 2012 at 4:44 PM, Burke Mamlin <bu...@openmrs.org> wrote:
> In the long run I don't believe that we want to depend on the OpenMRS
> organization in github for finding source code; rather, my hope is that
> we'll turn our efforts on making it easier to find source code wherever it
> is – e.g., improve our module repository and find a way (via naming
> conventions, README conventions, etc.) to locate source that has not been
> published to the module repository.  In short, aim toward an approach that
> still makes it easy to find source code of interest when there are 3000+
> OpenMRS-related repos around.

For what it's worth, FishEye can index multiple GitHub repositories.

Michael

[Mark Goodrich]

Fwiw, our Jira implementation does now support Git.  For an example, check out the “GitHub” tag under this ticket:

 

https://tickets.openmrs.org/browse/HTML-341

 

I think it is valid to discuss whether we want to keep all core modules under the “Openmrs” account on Github, or whether we allow people to maintain modules within their own Github repos (my vote would be to keep them centralized—although I realize I’m an offender right now with the Provider Management module in my own repo… I plan to move it before I do an official release), but as for having all modules in svn, for better or worse, that ship has sailed, as we’ve got three modules in the OpenMRS account on Github at this point and I sincerely doubt there will be motivation to move them back to svn:

 

https://github.com/OpenMRS

 

Mark

[Burke Mamlin]

It's nice to know, though it'd be nice to keep some core repos at the top of the list without depending on users to "favorite" them.  If we had hundreds/thousands of repos in FishEye, there might be more downsides than benefits.

I was thinking of something like taking the output of

$ curl https://api.github.com/legacy/repos/search/openmrs

and formatting it into a searchable web page with links.

-Burke

 

Michael

[Michael Downey]

On Wed, May 23, 2012 at 5:00 PM, Burke Mamlin <bu...@openmrs.org> wrote:
> I was thinking of something like taking the output of
> $ curl https://api.github.com/legacy/repos/search/openmrs
> and formatting it into a searchable web page with links.

That too. :-)

Michael

[Burke Mamlin]

Mark, you're not alone.  There are already 94 OpenMRS-related repositories in github.

I'd prefer not to spend our valuable cycles on trying to corral these efforts; rather, I'd like to embrace the distributed approach and focus our efforts, instead, on trying to make it easy to find things without making it harder to create them – i.e., we invest our time/efforts in making tools to easily navigate source across potentially thousands of repos.

We can always put some (even many) repos under the OpenMRS organization in github; I just don't want moving repos under the OpenMRS organization to be our only tool for organizing & getting people to repos.

-Burke

[Darius Jazayeri]

Burke, so to be concrete, if Mykola were to move the custommessages module to github, should he put it under OpenMRS, or elsewhere?

And if it goes under OpenMRS, which of these is the reason?

(a) because it's GSoC work, so he's wearing an OpenMRS hat

(b) because by default we let everyone put OpenMRS-related things under OpenMRS

(c) because it's such an awesome module that we want to officially support it

-Darius

[Rafal Korytkowski]

One thing to note is that distributed repositories may disappear at
any point and it would be good to use the OpenMRS repo at least to
fork ones we find valuable. It definitely needs to be done when we
plan to do a sprint on a particular project or in case of GSoC
projects.

It's important to note that we don't have to decide up front. GitHub
allows us to move a repo easily. We can also fork it and let it live
its own life or say from now on our fork is the master :-)

Summarizing (a) and (c) are good reasons for me, but not (b).

-Rafał

[Burke Mamlin]

Actually, I expected that Mykola would create the module under his own account unless he requested to put it under the OpenMRS organization.

In general, I would assume to find these repositories under the OpenMRS organization:

• Trunk if/when we decide to move it to github
• Core and distributed modules with source in github
• Some OpenMRS contribs
• Some non-core/non-distributed OpenMRS modules that are popular and/or supported by the community

I would assume to find these in github under user accounts:

• Some OpenMRS contribs
• Non-core/non-distributed OpenMRS modules created by the community

I have no problem with generic modules (those designed to work for many/all implementations) to live under the OpenMRS organization, but I would not require it.  If we are going to embrace distributed source control, I think we need to migrate away from the model where there is a "central repository" where all repos live.  For example, anyone searching github for "OpenMRS custommessage" would be able to find the source & they'd also be able to find the source via the module repository and/or wiki.

-Burke

[Darius Jazayeri]

Okay, so let me probe further. Here's the list of modules I currently have in my github account, along with where I think they should go, and why. (I'd actually like to get down to only having forks in my personal repo, and having all modules be owned by an organization.) Do you agree/disagree?

• openmrs-module-uiframework
• should go to PIH, until OpenMRS decides to adopt it as a supported module
• openmrs-module-uilibrary
• should go to PIH, until OpenMRS decides to adopt it as a supported module
• openmrs-module-appframework
• should go to PIH, until OpenMRS decides to adopt it as a supported module, if it ever does.
• openmrs-module-kenyaemr
• should go to ITECH
• openmrs-module-distribution
• this is already github.com/PIH/openmrs-module-moduledistro, I just forgot to delete my misnamed one. No reason not to move this to OpenMRS if OpenMRS wants to support it.
• openmrs-contrib-reportingpdiplugin
• should go to OpenMRS
• (metadatasharing, htmlformentry, and htmlformentry19ext, as forks of the OpenMRS ones)

Generally, I see you saying that things under /OpenMRS should be things that are popular/supported. What is the mechanism for deciding this? E.g. how should I decide whether to put "uiframework" under OpenMRS or PIH?

-Darius

[Burke Mamlin]

Darius,

If you're looking for the hard-and-fast rule, I don't have one for you.  When it's useful/helpful to use the OpenMRS organization in github we use it.  I'm fine with every module ever written in github going under OpenMRS… but good luck trying to accomplish that in a distributed world.  There are already 94 OpenMRS-related repositories in github of which only five our under the OpenMRS organization.  I have no desire to reduce the fun & flexibility of DVCS by policing repository locations.  I'm not worried about people hosting popular/useful modules under their accounts and then disappearing.  For example, etherpad-lite is a very popular nodejs-based version of etherpad… and, guess what, it lives under Pita's personal account and has been forked hundreds of times.

AFAIK there's only a couple downsides to transferring repositories if we put one somewhere and decide to move it later: (1) any forks need to update their remote url and (2) any links made to code from the mailing list or wiki or JIRA will break.  Neither of these is a deal-breaker, in my opinion.

Git ≠ Subversion.  In a distributed world, naming conventions & README files are more important than where the repository lives.  If code is useless it will be ignored (wherever it lives) and if it's very useful, it will be sought after (wherever it lives).  If we need a rule for using the OpenMRS organization in github, I would suggest starting with core & distributed modules.  I'm sure we'll change our mind over time.  The good news is, it's not a big deal.

What's the reason that you don't want a repo under your account?  Perhaps there's too much of a sense of individual responsibility?  And maybe you'll end up spending more time than you should on maintaining the repo?  That's as good of a case to host a repo under an organization as any – i.e., share the "ownership" and maintenance.

What's really going to rock our world is when there are 400 repositories of OpenMRS trunk.  Get ready.

-Burke

[Wesley Brown]

My 2 cents as an outsider: 

• I would assume that any github repositories under the OpenMRS organization are either official OpenMRS projects or projects with some oversight by the core OpenMRS developers (ie you people).
  
• The Modules area of wiki.openmrs.org seems like an better place to attempt to keep track of the module ecosystem.  This is where I intuitively went when I started trying to get my head around what modules are available.  I did this primarily because I expected that this would be a more complete list of active modules and would also have more information about the design, installation, and such.  So, while github does have a very nice readme display, I would much prefer to have a single place like the wiki for more higher-level module documentation and then just provide a link to the module repository on github.

-Wes

[Michael Seaton]

This all makes my head hurt.

To me, OpenMRS's move to GIT should not really change anything with regards to where people put their code.  Individuals and organizations have always had this choice - as we can see, if there are already 94 OpenMRS-related repositories in github, then people are already not using OpenMRS subversion for all of their modules.  At PIH, we also have a local svn repository with PIH-specific modules as well, though we try to use it as little as possible.  I know most other groups involved with OpenMRS have this kind of thing too.

So I don't think this conversation should be about whether we are trying to limit where people put their code.  But I do think it is useful for us to talk about where code-that-devs-would-previously-have-put-in-OpenMRS-svn should go in a GIT world.  And I also think it's important to talk about why doing so might make sense.  My opinion is that these should just go under the OpenMRS organization in GitHub, and not under anyone's personal account.

Burke - take your example below of Mykola's work on custommessages.  You said that you assumed that this would just go under his account.  But I originally wrote this module and put it in OpenMRS svn.  I'm happy that Mykola is expanding on it with these new features, and am happy that "ownership" is now shared, but I don't think that putting the master branch of this under Mykola's personal github account reflects this collaborative ownership.  Even if it makes absolutely no practical difference, I think the symbolic meaning of where code is hosted is important.  In this case, by putting it under OpenMRS it gives a sense of collaborative ownership across organizations in the OpenMRS ecosystem, and also reflects the goal that this be a module that is not built for a particular user or implementation.  This is important to me.

To me, the primary benefit of OpenMRS moving to GIT is to enable developers working in environments with poor connectivity to work with source control more effectively.  They can commit code locally, stash and revert changes without needing an internet connection.  They can work in small teams that are connected to each other but not to the internet at large, and share their code that way.  This is why I want us to move to GIT.  It has nothing to do, for me, with distributing the master code among dozens or hundreds of different accounts in GitHub.  I actually see this as a drawback, not as a benefit (but maybe I'll come around).

My 2 cents...
Mike

[Joaquín Blaya]

And perhaps it's slightly off topic, but for me as an implementer and pseudo-developer, the important thing is really having one spot where I can go and find the links to both the code and the documentation, so not a central repository of the code or documentation, but a centralized location of the links to them.

Joaquín
___________________________________________________________________
Gerente de Desarrollo, eHealth Systems
Research Fellow, Escuela de Medicina de Harvard
Moderador, GHDOnline.org

[Rowan Seymour]

Right now I have the Usage Statistics module under my own account at https://github.com/rowanseymour/openmrs-module-usagestatistics for a lack of anywhere else to put it (turns out after you've git for a while you physically can't go back to using SVN). Suranga wants to make some fixes so he'll fork it to his user account... and then we will have a Rowan version and a Suranga version. 

As Mike says, having it under my personal account doesn't reflect the sense of community ownership I want this module to have. I feel a bit weird about it even though I've written nearly all of the code, like it discourages others from working on it.

It's even weirder if it's a module that several people are actively developing.

But I'm not sure how else we can enforce proper source control without doing it this way. Every project should have a lead who makes the final decision about what get's pulled into the source code and what doesn't, even if there are lots of contributors to that project.

Maybe for some projects it will make sense to have multiple leads from the same organization so that could be implemented by creating a PIH github org and a Regenstrief github org etc

If this module was under the OpenMRS github organization then I don't think there is a sensible way to specifically give me pull rights on this module but not others. I think we could create separate teams for each repo under the organization but that would be awkward to maintain.

I agree with what Joaquín is saying - we need a good 'centralized' place for people to find these 'distributed' modules. Rather than rely on people to create wiki pages for their module - modules.openmrs.org should be the authority on where the official version of a given module resides, and who 'owns' a particular module ID. It shouldn't be the JIRA ticketing system because not every module developer wants to use the OpenMRS ticketing system.

Rowan Seymour
tel: +250 783835665
http://twitter.com/rowanseymour

[Ben Wolfe]

I think the openmrs account on github should be open to more than just core maintained modules.  If its in that repo we don't make any more claims of validity/testing/devs than if it were in svn.openmrs.org.  Giving owners pull rights to everything in the openmrs repo and using "social security" to keep people doing the right thing is how we've operated for 7 years now.  Everyone will commit rights in svn knows they have rights everywhere.  However, we've never had someone commit something malicious to trunk. I don't worry about it because 1) the repo watched 2) its tracked 3) commits are reversible.

The "central place to look" for modules should be the the wiki modules page: https://wiki.openmrs.org/display/docs/Modules

1) If a user hasn't shared their code in svn/git/etc they can still have a wiki page
2) If a user doesn't have a jira project, they still need documentation
3) If the module is documented elsewhere, the wiki page on openmrs.org can be barebones enough to hit on searches and just direct somewhere else that is maintained

Ben

[Michael Downey]

On Fri, May 25, 2012 at 7:51 AM, Rowan Seymour <rowans...@gmail.com> wrote:

> I agree with what Joaquín is saying - we need a good 'centralized' place for
> people to find these 'distributed' modules. Rather than rely on people to
> create wiki pages for their module - modules.openmrs.org should be the
> authority on where the official version of a given module resides, and who
> 'owns' a particular module ID. It shouldn't be the JIRA ticketing system
> because not every module developer wants to use the OpenMRS ticketing
> system.

+1

Michael

[Rowan Seymour]

I think your advocating for a source control workflow that we've used out of necessity rather than design. We haven't been able to manage proper permissions with our centralized SVN repo so we haven't. Git allows us to keep doing things this way, but it also gives the option of other workflows (http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows)

The whole git pull concept is powerful and it would seem a shame not to use it. Especially with lovely github pull requests.

I also don't think forcing users to document their modules in the OpenMRS wiki is consistent with our move toward more distributed development. Like for example here in Rwanda, we maintain our own documentation wiki. I'd rather just have a simple modules.openmrs.org that 

• Hosts an omod with an approved module id
• Links to documentation
• Links to code

[Justin Miranda]

In case you need an example, Grails supports two git "homes" (one for core and one for plugins). When I want to view the source code for a plugin I'm working with, in almost all cases it's under grails-plugins.  I would recommend a similar convention for OpenMRS.

https://github.com/grails

https://github.com/grails-plugins

Justin

[Burke Mamlin]

I like this.  How about modeling what's worked well thus far:

http://github.com/openmrs – for repos related to the core API/application

http://github.com/openmrs-modules – a home for any modules that want to be housed there (like our SVN)

http://github.com/openmrs-contrib – a home for contributions

As Rowan suggested, hopefully 80% or more of modules would have an entry in the module repository that points people to documentation & source.  We welcome, but don't require, module documentation in the wiki.  For anyone who does not feel comfortable hosting module source under their account, they can use the openmrs-modules organization.

-Burke

[Ben Wolfe]

SVN allows for complicated permissions if you want.  We tried it for a few months but realized its not necessary.  I make the same argument here.  I am not advocating against having a lot of personal forks against modules/core in the openmrs repo in other users' personal repos.  We should still have that, but we don't have to spend extra cycles thinking about who in the group has rights to get code into the main repo.  That should be done socially with written/spoken permissions granted.

I agree that a lot of people like to keep their own wikis, but is creating a stub in our wiki so difficult?

Using modules.openmrs.org as the end-all for looking for modules loses the half-done or not-yet-shared-as-an-omod modules.  Those type of modules are points for collaboration or for finishing off someone else's work instead of writing it all from scratch again.

Ben

[Darius Jazayeri]

Creating a stub in our wiki isn't hard. Maintaining it as things change is.

I think Burke's suggestion is a perfect solution: we have a script that searches github daily for all projects named "openmrs-module-%" and "openmrs-contrib-%" grabs the README, and throws all that in a table on modules.openmrs.org. (We can crawl other github equivalents too.)

-Darius

[Burke Mamlin]

Using modules.openmrs.org as the end-all for looking for modules loses the half-done or not-yet-shared-as-an-omod modules.  Those type of modules are points for collaboration or for finishing off someone else's work instead of writing it all from scratch again.

Perhaps this could be addressed via the module repository as well – i.e., migrate the process of establishing a module ID there, encouraging people to enter a description & links to any existing/planned documentation/source at that time.  This would also allow us to create module IDs that are namespaced to a developer UUID.  We could even evolve to a point where the module maven archetype used API calls (when a connection is available) to the module repository to automate these steps.  The module repository could show these entries in a "incubator" section and keep those things that are active up front, dropping inactive efforts to the background.

-Burke

[Ben Wolfe]

So modules.openmrs.org will contain unfinished modules as well? :-/

I like the idea of scouring git repos for READMEs.  Why not use that script to create/overwrite wiki page stubs ?

I want to push devs to put up more documentation than a standard README.  If a dev knows their README is going to the wiki (and github) they might be more inclined to put more information there.  (We'd need to translate the github format to wiki format though)

The idea is that if a group doesn't have a github readme and has their own docs elsewhere, a stub in our wiki doesn't have to be maintained.  It is only there because thats where people know to look. The page can have 2-3 very high level sentences and then a very visible link to the real docs.

Ben

[Jeremy Keiper]

Can't we just load the README into a div via Ajax instead of copying it in?

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support

[Rowan Seymour]

One complication of copying documention from README's into the wiki is you'd need to prevent people from editing that content on the wiki as it would be overwritten on the next script run. 

Rather than duplicating content, you could have modules.openmrs.org as the authoritive list of modules. Either it links to documentation in OpenMRS or documentation on github (which has its own wiki pages) or what ever link is parsed from the README.

[Burke Mamlin]

On Fri, May 25, 2012 at 9:27 AM, Ben Wolfe <b...@openmrs.org> wrote:

So modules.openmrs.org will contain unfinished modules as well? :-/

Yes.  Not appearing just like other modules; rather, in an incubation status.  For example, you search for "registration" and instead of seeing this:

• MRN Generator – Generate medical record numbers
• Registration – Registration Module is used to find/create patients. It can identify patients through biometric fingerprints, barcode id cards. It also captures patient images via a Flash component.
• Rwanda Primary Care Module – The touch-screen module used in Rwanda for primary care registration.  Features the Boabab touchscreen rendering library, as well as barcode printing.

you see something like:

• MRN Generator – Generate medical record numbers
• Registration – Registration Module is used to find/create patients. It can identify patients through biometric fingerprints, barcode id cards. It also captures patient images via a Flash component.
• Rwanda Primary Care Module – The touch-screen module used in Rwanda for primary care registration.  Features the Boabab touchscreen rendering library, as well as barcode printing.
• You  might also be interested in these works in progress (may be incomplete, require compiling, etc.):
• AMRS Registration – A patient registration system used by AMPATH in Kenya.
• New Registration – Registration for OpenMRS 1.8
• OpenHMIS Registration – An entry point of the data for all patient-related activities.  All forthcoming OpenHMIS modules that deal with patient data will rely on this registration module in some fashion, if only for the initial data that is collected.
• Remote Registration – Remote Registration Module is used to find/create patients. It can identify patients through barcode id cards. It can also register patients in offline mode.
• Visit Register – A Simple Patient Register for recording basic information pertaining to the visit

Ultimately, for finished as well as unfinished modules, it would be nice to have a automated measure of activity that would bring active projects into the forefront and allow stagnant work to fade into the background.

-Burke

[Darius Jazayeri]

By the way, this blog post is long, but very topical: http://blog.jquery.com/2011/12/08/what-is-happening-to-the-jquery-plugins-site/ . I'm going to excerpt a lot of it.

They say their plugin site

was a valuable tool when it was first set up, it gradually became something of awhite elephant for the project. While powerful distribution tools like GitHub and npm have come to the fore, we’ve been stuck in an aging, CMS-oriented paradigm that frustrated developers and consumers of plugins alike.

Their new approach is:

building out an infrastructure that’s backed by GitHub. There are two requirements for listing a plugin on the new site:

• A valid package.json file ... We’ve followed the lead of CommonJS and npm and created a schema for specifying dependencies, delivery, and other metadata of jQuery plugins. While the format is largely similar to those other projects, we’ve had to make some minor tweaks to account for some plugin-specific details.

• At least one versioned release ... This means having tagged your release point(s) with a valid semantic version number (semver) string.

We’ve pared down the submission and maintenance process to a single, one-time step: adding apost-receive hook to your plugin’s GitHub repository. Assuming your plugin meets the guidelines, a page will be created on the plugins site to present your usage and download information. We’ll keep track of new releases as you push them. 

My takeaway is that we could get a lot of bang-for-the-buck if we just:

1. allow the module's config.xml (or some other publish.xml or publish.json) to include links to where to find: (1) the source code (2) compiled omods, (3) documentation, (4) demo, (5) issue tracker. Some of this is probably in pom.xml already.
2. crawl github regularly to find these and build an index. We can also determine a simple measure of the project's activity while crawling.
3. modules.openmrs.org should allow you to search that index, post comments, and leave ratings, so we can show most-popular and highest-rated. (We can eventually incorporate info submitted by the atlas module.)
4. While we do this we should address the other glaring complaint people have with the module repo, in that it doesn't allow you to show a proper matrix of OpenMRS version compatibility.

Ben, speaking as someone who is currently working on ~5 new modules with very generic functionality that I want to share, but with a tight implementation deadline, I have less than zero time to document anything on a wiki for external consumption right now. If some automated tooling could pull details out of my module's pom.xml and config.xml, and look at its github tags and activity (and ideally even incorporate version changelogs from the tickets.openmrs.org project) then the work I'm doing would be publicly visible in a common place. If I'm required to do anything beyond linking my work to tickets, then it just won't happen "until I have time". (And we know when that is...)

-Darius

[Michael Downey]

FWIW, I personally think it's still worth exploring what kind of
Python chops we need to customize Zamboni [0] to work for OpenMRS.
Paul was going to try get a contact at Mozilla to chat with us about
what might be necessary from their perspective.

Michael

[0] http://mozilla.github.com/zamboni/

[Jeremy Keiper]

We have chops within the team, just need to know the customization path.

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support

[Ben Wolfe]

Ok, if we did some heavy modifications/rewrite to modules.openmrs.org I can now see it being the go-to place.  I'd like to see that work done sooner rather than later.

Darius, your love for documentation never ceases to amaze me. ;-)  If we went this new tactic, do you think you would have time to fill out the README for each of those to a state where someone else can reuse your module?  (if so, can you please put it in writing and sign/send it to me)

I really like the idea of tagging your module automatically updating the modules.openmrs.org released version.  Best practices all around.  Now we would just need to add a hook to make it also publish to mavenrepo.openmrs.org at the same time and we will have the perfect solution!

Ben

[Friedman, Roger (CDC/CGH/DGHA) (CTR)]

There should be some link between module (and core?) code and documentation, both design and user.  I'm not sure whether the wiki should point to documents in the version control store or the version control store should point to documents in the wiki.  But since the authors of the docs are the same people who are writing the code, it seems to make sense to keep the documents in version control.

[Michael Downey]

On Friday, May 25, 2012 8:56:14 AM UTC-4, Burke Mamlin wrote:

http://github.com/openmrs – for repos related to the core API/application

http://github.com/openmrs-modules – a home for any modules that want to be housed there (like our SVN)

http://github.com/openmrs-contrib – a home for contributions

Can someone help me understand the benefit of having separate GitHub Organizations vs. what we have now--one Organization with repositories with permissions assigned to various Teams? Anyone can create a file on GitHub and once it's there, that repo can be easily moved between users and organizations. It's part of the distributed conceptual model to have individuals or organizations responsible for code and other individuals (or other organizations) forking, making changes, and pushing those changes back--and these forks are actually well-tracked when the activity stays within GitHub [0].

It's worth remembering that Organizations are a somewhat new feature to GitHub and were designed to help centralize all of a project's code and make it easier to find, not to further fragment it. [1] :-)  Also, -1 for having to manage multiple organizations and permissions when people can already host stuff on GitHub anyway. From where I stand, It seems splitting things out into several organizations doesn't really buy us much, but does make it more difficult to track stuff down, but I might be missing something.

Michael

[0] https://github.com/OpenMRS/openmrs-module-htmlformentry/network

[1] https://github.com/blog/674-introducing-organizations

[Burke Mamlin]

That's a fair point.  And it looks like the grails-plugins "organization" was created more than a year before organizations were introduced into github.  While the separate URLs sounded nice at first, I'd agree that we're better off following github's intent for organizations to represent, er, an organization while avoiding the pain of managing organization members across multiple pseudo-organizations.  Even if we have 300 repositories within the organization, github makes it pretty trivial to find a repository by keyword.

-Burke

-- OpenMRS Developers: http://go.openmrs.org/dev
Post: d...@openmrs.org
Unsubscribe: dev+uns...@openmrs.org

[Darius Jazayeri]

I think the distinction we're trying to make is between code that is "officially supported" vs not.

So an alternate take on this would be to have:

* github.com/openmrs

* github.com/openmrs-unofficial

-Darius

-- OpenMRS Developers: http://go.openmrs.org/dev
Post: d...@openmrs.org
Unsubscribe: dev+uns...@openmrs.org

[Jeremy Keiper]

I prefer "community" to "unofficial".

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support

[Burke Mamlin]

But do we really need to distinguish between OpenMRS and OpenMRS Community by repository location?  We don't currently do this in SVN and have been getting along okay.  I'm okay with anyone's OpenMRS-related work going under the OpenMRS organization in github.

-Burke

[Michael Downey]

On Wed, May 30, 2012 at 4:35 PM, Burke Mamlin <bu...@openmrs.org> wrote:
> But do we really need to distinguish between OpenMRS and OpenMRS Community
> by repository location?  We don't currently do this in SVN and have been
> getting along okay.  I'm okay with anyone's OpenMRS-related work going under
> the OpenMRS organization in github.

Let us not forget we can designate "official OpenMRS-supported code"
in the README's or other repo-specific information within GitHub.

Michael

[Darius Jazayeri]

I definitely wouldn't want "openmrs" vs "openmrs-community". Because those are the same thing. :-) I was suggesting more like having "-unofficial" or "-unsupported".

If others don't see a need for it, fine by me.

-Darius

[Ben Wolfe]

I think we will be fine with just one account.  If someone is digging through git looking for code they either:
a) can look at the README to know the author/intent/    or 
b) know its unsupported/unloved because they couldn't get the compiled version they want from the module repository

Ben

[Burke Mamlin]

So, to summarize, I believe we're settling on an approach that closely mirrors our existing SVN repository – i.e., anyone working on openmrs-related code in github is welcome & encouraged to host their code under the OpenMRS organization and we'll probably end up with a similar process (e.g., write to co...@openmrs.org) to get a repository within the organization, ensuring repos within the organization follow naming conventions.  Otherwise, we still encourage folks within their own accounts to use the "openmrs-module-moduleid" & "openmrs-contrib-name" + README conventions when creating repos to make their personal repos accessible/identifiable to the community.

By convention, any community-supported modules hosted in github would be expected/assumed to be found within the OpenMRS organization.

Cheers,

-Burke