Saptarshi, I think we all want to have a single place to go to find out what is going on around OpenMRS; however, requiring that it be in a single repository is overly constraining. It's not that we have a problem hosting code… and we can continue do that; rather, we don't want to continue in a model where * not* hosting your code within the OpenMRS repository makes your code any less part of the community. Migrating toward DVCS highlights this, since it's much easier for people just to create a repository when they want one.
Ideally, the module repository would grow to fill this need, becoming an easily searchable repository of available modules with descriptions, user ratings, tags, compatibility reports, and links to source code for each. In the meantime, we could work on a poor man's version by programmatically creating a list of available modules that would span the OpenMRS repository, GitHub, and potentially other popular locations of repositories – e.g., scan each resource; collect at least module name, URL, README, and a timestamp for last commit from each, then present those in a searchable list. Naming conventions in GitHub (e.g., openmrs-module-*moduleid*) would help. -Burke On Tue, May 15, 2012 at 1:21 AM, Saptarshi Purkayastha <sun...@gmail.com>wrote: > I would like OpenMRS module distribution and also the source code > distribution (including the maven repo) through one place... Although if > someone would like to do their development outside of OpenMRS's > repositories that's fine... But I think finding OpenMRS information is > already pretty distributed. This only adds to the trouble of finding module > source in different repositories on the wild web. > There have been so many times that I have been able to find other people's > modules useful and easy to find from the svn repo. Just when someone > discusses the module name, you know its location and you can expect its > source code URL. > > Does OpenMRS have a problem with hosting source code lately?? > Are we doing this only because we love github and DVCS so much?? Surely, > the c...@o.org isn't that big a bottleneck. If someone thinks it is > (which happens when you want to name a module something, code managers will > not let u select your fav name), you can always code somewhere else. But > IMO generally that discussion on name improves things > > --- > Regards, > Saptarshi PURKAYASTHA > > My Tech Blog: http://sunnytalkstech.blogspot.com > You Live by CHOICE, Not by CHANCE > > > > On 15 May 2012 09:16, Burke Mamlin <bmam...@regenstrief.org> wrote: > >> I'm not sure I would make it so formal. In general, I would expect to >> find trunk and core, community-supported modules within >> http://github.com/OpenMRS/, I wouldn't want to preclude having >> community-supported modules hosted elsewhere. >> >> We need to shift our thinking/efforts from organizing code based on a >> centralized repository and, instead, find ways (e.g., via naming & README >> conventions, registration of modules, an improved module repository, etc.) >> to organize a living, breathing landscape of code in a way that makes it >> easy for the community to locate existing efforts and self-identify >> redundant efforts. >> >> -Burke >> >> On Mon, May 14, 2012 at 10:37 PM, Darius Jazayeri <dar...@openmrs.org>wrote: >> >>> Moving this discussion to the dev list. >>> >>> I've committed version 1 of a module that lets you upload a zip file >>> full of omods. >>> >>> I was going to call it "distribution" but Burke didn't like that, so I >>> called it "moduledistro" instead. >>> >>> I shared it at https://github.com/PIH/openmrs-module-moduledistro >>> >>> My working assumption is that anything that we put in >>> https://github.com/OpenMRS/openmrs-module-* promises some level of >>> support from OpenMRS (e.g. it's a candidate for voting for features or >>> bugfixes, and we'd try to have sprints to push it forwards). But that we >>> won't put modules there unless we've decided to provide some level of >>> support. Basically it's the equivalent of "core + bundled modules". >>> >>> Thus I shared this module under PIH's github instead, where OpenMRS >>> doesn't promise any support. (PIH doesn't promise support either, for that >>> matter, but that's not relevant here...) >>> >>> What do others think? >>> >>> -Darius >>> >>> >>> On Mon, May 14, 2012 at 7:22 PM, Burke Mamlin <bu...@openmrs.org> wrote: >>> >>>> It doesn't matter too much, although it's probably better/easier to >>>> move a repository into the organization sooner than later, since it does >>>> have some ramifications – e.g., any clones have to update their remote, >>>> documentation needs to be updated, and any links in mailing list archives/ >>>> answers.openmrs.org/etc. will break. >>>> >>>> In the end, I think it's better for us to focus on efficient ways on >>>> tracking/locating/organizing the work that's going on instead of trying to >>>> control it. >>>> >>>> -Burke >>>> >>>> >>>> On Mon, May 14, 2012 at 9:52 PM, Darius Jazayeri <dar...@openmrs.org>wrote: >>>> >>>>> More to the point, I want to clarify that you all agree with me that >>>>> in the new world of DVCS, OpenMRS does *not* want modules to be >>>>> created in OpenMRS's github account until a later stage in their >>>>> lifecycle. >>>>> Right? >>>>> >>>>> -Darius >>>>> >>>>> >>>>> On Mon, May 14, 2012 at 6:49 PM, Burke Mamlin <bu...@openmrs.org>wrote: >>>>> >>>>>> Yup. Vetting a module ID does not imply OpenMRS ownership. >>>>>> >>>>>> -Burke >>>>>> >>>>>> >>>>>> On Mon, May 14, 2012 at 4:49 PM, Ben Wolfe <b...@openmrs.org> wrote: >>>>>> >>>>>>> I don't see a problem with it. I personally think module code can >>>>>>> be stored anywhere, as long as its public and documented. (unless >>>>>>> someone >>>>>>> is developing a closed source module, then it has to be elsewhere and >>>>>>> private) >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> >>>>>>> On Mon, May 14, 2012 at 4:43 PM, Darius Jazayeri <dar...@openmrs.org >>>>>>> > wrote: >>>>>>> >>>>>>>> Okay, moduledistro it is. >>>>>>>> >>>>>>>> So, just to clarify, even though I've reserved this moduleId from >>>>>>>> OpenMRS (which I will use to publish to the module repo and to maven), >>>>>>>> OpenMRS has no problem with me storing the code in >>>>>>>> github.com/PIH/openmrs-module-moduledistro? >>>>>>>> >>>>>>>> (I think the point is that OpenMRS's github account is only for >>>>>>>> modules that OpenMRS wants to actively support, so I'd assume that >>>>>>>> OpenMRS >>>>>>>> doesn't *want* this module.) >>>>>>>> >>>>>>>> -Darius >>>>>>>> >>>>>>>> >>>>>>>> On Mon, May 14, 2012 at 1:20 PM, Burke Mamlin <bu...@openmrs.org>wrote: >>>>>>>> >>>>>>>>> +1 for moduledistro >>>>>>>>> >>>>>>>>> On Mon, May 14, 2012 at 4:06 PM, Ben Wolfe <b...@openmrs.org>wrote: >>>>>>>>> >>>>>>>>>> moduledistro seems reasonable. I like that a lot more than >>>>>>>>>> distribution >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, May 14, 2012 at 2:05 PM, Darius Jazayeri < >>>>>>>>>> dar...@openmrs.org> wrote: >>>>>>>>>> >>>>>>>>>>> They were options for file extensions. But I had in mind using >>>>>>>>>>> the same thing as the module id. >>>>>>>>>>> >>>>>>>>>>> I assume we'll eventually bring this into core, but I'm not >>>>>>>>>>> thinking about that now. >>>>>>>>>>> >>>>>>>>>>> It *does* support managing distributions, for me. It lets me >>>>>>>>>>> distribute my distro as a zip of omods, and it will let me >>>>>>>>>>> distribute by >>>>>>>>>>> publishing a new version of the zip to a URL. >>>>>>>>>>> >>>>>>>>>>> "Module Loader" isn't descriptive because that doesn't imply >>>>>>>>>>> that this supports a zip/package/distro of modules. >>>>>>>>>>> >>>>>>>>>>> If you don't like "distribution" or "distro", how >>>>>>>>>>> about "omodzip" or "moduledistro"? >>>>>>>>>>> >>>>>>>>>>> -Darius >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sat, May 12, 2012 at 10:51 AM, Burke Mamlin < >>>>>>>>>>> bu...@openmrs.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Oh. I thought ozip vs. opack vs. omg were options for the file >>>>>>>>>>>> extension, not the module ID. >>>>>>>>>>>> >>>>>>>>>>>> "distribution" doesn't really say what this module does. How >>>>>>>>>>>> about moduleloader? Isn't our eventual goal to bring this >>>>>>>>>>>> functionality >>>>>>>>>>>> into core and make a single function for uploading modules that >>>>>>>>>>>> accepts a >>>>>>>>>>>> single module or a group of modules? >>>>>>>>>>>> >>>>>>>>>>>> -Burke >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sat, May 12, 2012 at 1:34 AM, Darius Jazayeri < >>>>>>>>>>>> djazay...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I'm not 100% sold on the name myself (and I couldn't think of >>>>>>>>>>>>> any good alternatives after rejecting ozip and opack), but I'm at >>>>>>>>>>>>> least 85% >>>>>>>>>>>>> sold. >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, for the Kenya project my intention is for the >>>>>>>>>>>>> distribution to be a zip containing ~10 omods. One of them (the >>>>>>>>>>>>> "Kenya EMR" >>>>>>>>>>>>> module) will contain all the content (in the form of metadata >>>>>>>>>>>>> sharing >>>>>>>>>>>>> packages) and skinning. >>>>>>>>>>>>> >>>>>>>>>>>>> I.e. you could take the vanilla standalone, choose the MVP >>>>>>>>>>>>> Dictionary installation option, add the distribution module, >>>>>>>>>>>>> install the >>>>>>>>>>>>> "Kenya EMR Distro v1.zip", and you've got the whole setup. And the >>>>>>>>>>>>> mechanism for upgrading an installation will be pushing out a new >>>>>>>>>>>>> version >>>>>>>>>>>>> of the distro zip. (I don't have a plan for upgrading core yet.) >>>>>>>>>>>>> >>>>>>>>>>>>> In practice Bill wants to distribute this as a VM rather than >>>>>>>>>>>>> the standalone, which I agree with, but you *could* configure >>>>>>>>>>>>> the standalone that way. >>>>>>>>>>>>> >>>>>>>>>>>>> So to sum up, the module is intended to allow you to manage a >>>>>>>>>>>>> "distribution" (though its functionality now is rather limited). >>>>>>>>>>>>> I'd >>>>>>>>>>>>> welcome alternate naming suggestions. >>>>>>>>>>>>> >>>>>>>>>>>>> -Darius >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, May 11, 2012 at 9:26 PM, Burke Mamlin < >>>>>>>>>>>>> bu...@openmrs.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Not a big fan of the name choice, since we've already been >>>>>>>>>>>>>> using the term OpenMRS Distribution to represent a flavor of >>>>>>>>>>>>>> OpenMRS (the >>>>>>>>>>>>>> platform + content, skinned UI, etc.) – e.g., Kenya is >>>>>>>>>>>>>> considering making >>>>>>>>>>>>>> an OpenMRS Distribution for Kenya that would be a flavor of >>>>>>>>>>>>>> OpenMRS >>>>>>>>>>>>>> pre-configured to Kenyan specifications. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is the intent that the zipped modules would also include all >>>>>>>>>>>>>> of the content (dictionary, forms, reports, etc.) and UI >>>>>>>>>>>>>> skinning to turn a >>>>>>>>>>>>>> virgin version of OpenMRS, say the standalone, into a flavor of >>>>>>>>>>>>>> OpenMRS (an >>>>>>>>>>>>>> OpenMRS Distribution)? >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Burke >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, May 11, 2012 at 7:39 PM, Darius Jazayeri < >>>>>>>>>>>>>> djazay...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've created a module that I'm calling "distribution". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The code lives at >>>>>>>>>>>>>>> https://github.com/djazayeri/openmrs-module-distribution >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It currently allows you to upload a ZIP full of OMODs and it >>>>>>>>>>>>>>> installs them in one operation. In the future it will also >>>>>>>>>>>>>>> support letting >>>>>>>>>>>>>>> the zip include an update url, so the module can proactively >>>>>>>>>>>>>>> download new >>>>>>>>>>>>>>> versions of the distribution zip, and prompt the sysadmin to >>>>>>>>>>>>>>> install them >>>>>>>>>>>>>>> with one click. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can I have the id "distribution" so I can upload 1.0 of this >>>>>>>>>>>>>>> to the module repository and deploy it to the maven repo? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Darius >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> ------------------------------ >>> Click here to >>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >> >> >> > ------------------------------ > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
