Re: Request module id: distribution

classic Classic list List threaded Threaded
5 messages Options
Darius Jazayeri-4 Darius Jazayeri-4
Reply | Threaded
Open this post in threaded view
|

Re: Request module id: distribution

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.


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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Yup. Vetting a module ID does not imply OpenMRS ownership.

-Burke


On Mon, May 14, 2012 at 4:49 PM, Ben Wolfe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
+1 for moduledistro

On Mon, May 14, 2012 at 4:06 PM, Ben Wolfe <[hidden email]> wrote:
moduledistro seems reasonable.  I like that a lot more than distribution


On Mon, May 14, 2012 at 2:05 PM, Darius Jazayeri <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi All,

I've created a module that I'm calling "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













[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Request module id: distribution

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 <[hidden email]> 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.


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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Yup. Vetting a module ID does not imply OpenMRS ownership.

-Burke


On Mon, May 14, 2012 at 4:49 PM, Ben Wolfe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
+1 for moduledistro

On Mon, May 14, 2012 at 4:06 PM, Ben Wolfe <[hidden email]> wrote:
moduledistro seems reasonable.  I like that a lot more than distribution


On Mon, May 14, 2012 at 2:05 PM, Darius Jazayeri <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi All,

I've created a module that I'm calling "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













[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
sunbiz sunbiz
Reply | Threaded
Open this post in threaded view
|

Re: Request module id: distribution

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 [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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.


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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Yup. Vetting a module ID does not imply OpenMRS ownership.

-Burke


On Mon, May 14, 2012 at 4:49 PM, Ben Wolfe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
+1 for moduledistro

On Mon, May 14, 2012 at 4:06 PM, Ben Wolfe <[hidden email]> wrote:
moduledistro seems reasonable.  I like that a lot more than distribution


On Mon, May 14, 2012 at 2:05 PM, Darius Jazayeri <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi All,

I've created a module that I'm calling "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













[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list
Wesley Brown Wesley Brown
Reply | Threaded
Open this post in threaded view
|

Re: Request module id: distribution

While I agree that being able to find module code is very important for other module developers (it certainly has been for me), the primary mechanism that I have used to find that code is the module listing on wiki.openmrs.org.  As long as I can get a high-level view of the module functionality and discover where it is hosted, I am content.  I really don't care where the code repository is actually hosted, provided that it is publicly available. 

I much prefer a DVCS like git over svn because I work in an area where the internet is often down which means I cannot commit until the connection is back up.  Given that we have chosen git for our version control system, github is the natural place to host that online and provides a great set of features for free.  This is why we have created the OpenHMIS repo on github and, once we are far enough along, will hopefully register our module at the appropriate places on openmrs.org with links to our source and other content on github.  That said, we assumed that this was an accepted practice for the module development community at large... is that actually the case?

-Wes

On Tue, May 15, 2012 at 8:21 AM, Saptarshi Purkayastha <[hidden email]> 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 [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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.


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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Yup. Vetting a module ID does not imply OpenMRS ownership.

-Burke


On Mon, May 14, 2012 at 4:49 PM, Ben Wolfe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
+1 for moduledistro

On Mon, May 14, 2012 at 4:06 PM, Ben Wolfe <[hidden email]> wrote:
moduledistro seems reasonable.  I like that a lot more than distribution


On Mon, May 14, 2012 at 2:05 PM, Darius Jazayeri <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi All,

I've created a module that I'm calling "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













[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Request module id: distribution

In reply to this post by sunbiz
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 <[hidden email]> 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 [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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.


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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Yup. Vetting a module ID does not imply OpenMRS ownership.

-Burke


On Mon, May 14, 2012 at 4:49 PM, Ben Wolfe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
+1 for moduledistro

On Mon, May 14, 2012 at 4:06 PM, Ben Wolfe <[hidden email]> wrote:
moduledistro seems reasonable.  I like that a lot more than distribution


On Mon, May 14, 2012 at 2:05 PM, Darius Jazayeri <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi All,

I've created a module that I'm calling "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













[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list