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 _________________________________________ 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]
