Future of GitHub open-lmis repository?

As we continue to move forward with OpenLMIS v3 and the future of OpenLMIS being composed of multiple Independent Services, each within their own git repository, there is a question that the technical community should address pertaining to the future role of the open-lmis GitHub repository. This is under question as the bulk of the code within this repository will, in v3, be found within multiple Independent Services, and so by and large, open-lmis would be very lean in OpenLMIS v3.

There are two obvious options:

  1. The open-lmis repository continues into version 3 and beyond and becomes a lean repository. Meaning that most of the Java, Javascript, etc code which comprise its features is removed from the dev & master branches. In v3 and beyond it’ll hold container management code/scripts that defines the OpenLMIS Reference Distribution (that which composes the Services and other infrastructure). All v1 through v2 code is NOT purged from the git history and will continue to be accessible through tags and support branches for fixing bugs, etc.

  2. The open-lmis repository does not play a role in v3. OpenLMIS v1 and v2 will of course stay in open-lmis, however a new yet-to-be-named repository would be used for v3 code/scripts.

Option 2’s big pro is that is avoids the scary / weird code “removal” commit. It would also provide a nice clean break and the git history would be small because the source would be small - meaning a fast git clone. It’s con however is that a new repository would be “the OpenLMIS” and the open-lmis repo would essentially become a legacy repo that only contained version 1 and 2.

I’ve stated my bias above and the pros / cons as I see them. That all said, I’m interested in your thoughts on options 1 or 2?

Ideally we could discuss here and the technical committee could make this decision here, however if we think we need to we can also put this on the next tech-call’s agenda. Please let me know this week as we do need to move forward rather soon.

Thanks!

Best,
Josh

···

From my perspective, I think option 1 has the most consistency with the community. The pros would include maintaining a consistent git repository for all OpenLMIS versions. It would also keep our current repository stars (50), watches (53), forks (30) etc. The cons I think would primarily be that there would be a big commit that would remove most of the source code from the HEAD of dev and eventually master branches and that might look scary/weird.

My preference, as non-tech committee member, is option 2. The code and intent of the reference distribution is incongruent with the current content of the open-lmis repo. The git history is of little value. I don’t think 50 watchers is a large enough of a community to worry about confusion. We can direct folks accordingly with text in the repo description and at the head of the README.

Rich

···

As we continue to move forward with
OpenLMIS v3
and the future of OpenLMIS being composed of multiple Independent Services, each within their own git repository, there is a question that the technical community should address pertaining to the future role of the open-lmis GitHub repository. This is under question as the bulk of the code within this repository will, in v3, be found within multiple Independent Services, and so by and large, open-lmis would be very lean in OpenLMIS v3.

There are two obvious options:

  1. The open-lmis repository continues into version 3 and beyond and becomes a lean repository. Meaning that most of the Java, Javascript, etc code which comprise its features is removed from the dev & master branches. In v3 and beyond it’ll hold container management code/scripts that defines the OpenLMIS Reference Distribution (that which composes the Services and other infrastructure). All v1 through v2 code is NOT purged from the git history and will continue to be accessible through tags and support branches for fixing bugs, etc.

  2. The open-lmis repository does not play a role in v3. OpenLMIS v1 and v2 will of course stay in open-lmis, however a new yet-to-be-named repository would be used for v3 code/scripts.

From my perspective, I think option 1 has the most consistency with the community. The pros would include maintaining a consistent git repository for all OpenLMIS versions. It would also keep our current repository stars (50), watches (53), forks (30) etc. The cons I think would primarily be that there would be a big commit that would remove most of the source code from the HEAD of dev and eventually master branches and that might look scary/weird.

Option 2’s big pro is that is avoids the scary / weird code “removal” commit. It would also provide a nice clean break and the git history would be small because the source would be small - meaning a fast git clone. It’s con however is that a new repository would be “the OpenLMIS” and the open-lmis repo would essentially become a legacy repo that only contained version 1 and 2.

I’ve stated my bias above and the pros / cons as I see them. That all said, I’m interested in your thoughts on options 1 or 2?

Ideally we could discuss here and the technical committee could make this decision here, however if we think we need to we can also put this on the next tech-call’s agenda. Please let me know this week as we do need to move forward rather soon.

Thanks!

Best,

Josh

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/fb6fd036-591c-4392-98bd-aa4686ceea5c%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

I agree with Rich. Strong vote for #2.

Having the master branch of the existing repository suddenly delete all the files and become something completely different would violate the principle of least surprise, and none of the current watches and forks would actually want this to happen.

-Darius

···

On Thu, May 12, 2016 at 10:47 AM, Rich Magnuson rich.magnuson@villagereach.org wrote:

My preference, as non-tech committee member, is option 2. The code and intent of the reference distribution is incongruent with the current content of the open-lmis repo. The git history is of little value. I don’t think 50 watchers is a large enough of a community to worry about confusion. We can direct folks accordingly with text in the repo description and at the head of the README.

Rich

From: openlmis-dev@googlegroups.com [mailto:openlmis-dev@googlegroups.com] On Behalf Of Josh Zamor

Sent: Tuesday, May 10, 2016 5:41 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Future of GitHub open-lmis repository?

As we continue to move forward with
OpenLMIS v3
and the future of OpenLMIS being composed of multiple Independent Services, each within their own git repository, there is a question that the technical community should address pertaining to the future role of the open-lmis GitHub repository. This is under question as the bulk of the code within this repository will, in v3, be found within multiple Independent Services, and so by and large, open-lmis would be very lean in OpenLMIS v3.

There are two obvious options:

  1. The open-lmis repository continues into version 3 and beyond and becomes a lean repository. Meaning that most of the Java, Javascript, etc code which comprise its features is removed from the dev & master branches. In v3 and beyond it’ll hold container management code/scripts that defines the OpenLMIS Reference Distribution (that which composes the Services and other infrastructure). All v1 through v2 code is NOT purged from the git history and will continue to be accessible through tags and support branches for fixing bugs, etc.

  2. The open-lmis repository does not play a role in v3. OpenLMIS v1 and v2 will of course stay in open-lmis, however a new yet-to-be-named repository would be used for v3 code/scripts.

From my perspective, I think option 1 has the most consistency with the community. The pros would include maintaining a consistent git repository for all OpenLMIS versions. It would also keep our current repository stars (50), watches (53), forks (30) etc. The cons I think would primarily be that there would be a big commit that would remove most of the source code from the HEAD of dev and eventually master branches and that might look scary/weird.

Option 2’s big pro is that is avoids the scary / weird code “removal” commit. It would also provide a nice clean break and the git history would be small because the source would be small - meaning a fast git clone. It’s con however is that a new repository would be “the OpenLMIS” and the open-lmis repo would essentially become a legacy repo that only contained version 1 and 2.

I’ve stated my bias above and the pros / cons as I see them. That all said, I’m interested in your thoughts on options 1 or 2?

Ideally we could discuss here and the technical committee could make this decision here, however if we think we need to we can also put this on the next tech-call’s agenda. Please let me know this week as we do need to move forward rather soon.

Thanks!

Best,

Josh

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/fb6fd036-591c-4392-98bd-aa4686ceea5c%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/BN1PR02MB0218D175D7BE5516538E90493730%40BN1PR02MB021.namprd02.prod.outlook.com.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

Hi all,

Not voting one way or the other, however, if we go the route of #2 why not put a note on the top of v2 readme stating that 2.0 is a deprecated version and linking to v3 for new deployments?

Cheers,

···

Kevin Cussen | kevin.cussen@villagereach.org

Manager, Information Systems

Village****Reach Starting at the Last Mile

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: 1.206.604.4209 FAX: 1.206.860.6972

SKYPE: kevin.cussen.vr

www.villagereach.org

Connect on Facebook,
Twitter and our Blog


From: openlmis-dev@googlegroups.com openlmis-dev@googlegroups.com on behalf of Darius Jazayeri djazayer@thoughtworks.com

Sent: Thursday, May 12, 2016 12:45

To: Rich Magnuson

Cc: Josh Zamor; OpenLMIS Dev

Subject: Re: [openlmis-dev] Future of GitHub open-lmis repository?

I agree with Rich. Strong vote for #2.

Having the master branch of the existing repository suddenly delete all the files and become something completely different would violate the principle of least surprise, and none of the current watches and forks would actually want this to happen.

-Darius

On Thu, May 12, 2016 at 10:47 AM, Rich Magnuson
rich.magnuson@villagereach.org wrote:

My preference, as non-tech committee member, is option 2. The code and intent of the reference distribution is incongruent with the current content of the open-lmis repo. The git history is of little value. I don’t think 50 watchers is a large enough of a community to worry about confusion. We can direct folks accordingly with text in the repo description and at the head of the README.

Rich

From:
openlmis-dev@googlegroups.com [mailto:openlmis-dev@googlegroups.com] On Behalf Of Josh Zamor

Sent: Tuesday, May 10, 2016 5:41 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Future of GitHub open-lmis repository?

As we continue to move forward with
OpenLMIS v3
and the future of OpenLMIS being composed of multiple Independent Services, each within their own git repository, there is a question that the technical community should address pertaining to the future role of the open-lmis GitHub repository. This is under question as the bulk of the code within this repository will, in v3, be found within multiple Independent Services, and so by and large, open-lmis would be very lean in OpenLMIS v3.

There are two obvious options:

  1. The open-lmis repository continues into version 3 and beyond and becomes a lean repository. Meaning that most of the Java, Javascript, etc code which comprise its features is removed from the dev & master branches. In v3 and beyond it’ll hold container management code/scripts that defines the OpenLMIS Reference Distribution (that which composes the Services and other infrastructure). All v1 through v2 code is NOT purged from the git history and will continue to be accessible through tags and support branches for fixing bugs, etc.

  2. The open-lmis repository does not play a role in v3. OpenLMIS v1 and v2 will of course stay in open-lmis, however a new yet-to-be-named repository would be used for v3 code/scripts.

From my perspective, I think option 1 has the most consistency with the community. The pros would include maintaining a consistent git repository for all OpenLMIS versions. It would also keep our current repository stars (50), watches (53), forks (30) etc. The cons I think would primarily be that there would be a big commit that would remove most of the source code from the HEAD of dev and eventually master branches and that might look scary/weird.

Option 2’s big pro is that is avoids the scary / weird code “removal” commit. It would also provide a nice clean break and the git history would be small because the source would be small - meaning a fast git clone. It’s con however is that a new repository would be “the OpenLMIS” and the open-lmis repo would essentially become a legacy repo that only contained version 1 and 2.

I’ve stated my bias above and the pros / cons as I see them. That all said, I’m interested in your thoughts on options 1 or 2?

Ideally we could discuss here and the technical committee could make this decision here, however if we think we need to we can also put this on the next tech-call’s agenda. Please let me know this week as we do need to move forward rather soon.

Thanks!

Best,

Josh

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/fb6fd036-591c-4392-98bd-aa4686ceea5c%40googlegroups.com
.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/BN1PR02MB0218D175D7BE5516538E90493730%40BN1PR02MB021.namprd02.prod.outlook.com
.

For more options, visit
https://groups.google.com/d/optout
.

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R5LWYtYU%2BBRgt_hE2iYuSoWdSQRPOTw82ga13OSK0HKbw%40mail.gmail.com
.

For more options, visit https://groups.google.com/d/optout.

I do think that redirection has its benefits. To me however if I came upon the result of option 2 I’d be surprised:

  1. the open-lmis repository in the OpenLMIS organization, wouldn’t have anything to do with future OpenLMIS versions. That seems counter-intuitive, even with a redirection message
  2. version changes and active development have always occurred in the open-lmis repository. Master and dev are always changing. Moving old code is what happens as development occurs. The jump from v1 to v2 was in the area of 6000 commits, thousands of new files and ~2 years apart. No one at the repository level was effected.
  3. v1 through v2 code is in the open-lmis repository. I can git checkout from one to the other quickly. Why shouldn’t the starting point of v3 be the same?

Good feedback, keep it coming.

Best,

Josh

···

Kevin Cussen | kevin.cussen@villagereach.org

Manager, Information Systems

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: 1.206.604.4209 FAX: 1.206.860.6972

SKYPE: kevin.cussen.vr

www.villagereach.org

Connect on Facebook, Twitter** ** and our Blog


From: openlmis-dev@googlegroups.com <openlmis-dev@googlegroups.com > on behalf of Darius Jazayeri djazayer@thoughtworks.com

Sent: Thursday, May 12, 2016 12:45

To: Rich Magnuson

Cc: Josh Zamor; OpenLMIS Dev

Subject: Re: [openlmis-dev] Future of GitHub open-lmis repository?

I agree with Rich. Strong vote for #2.

Having the master branch of the existing repository suddenly delete all the files and become something completely different would violate the principle of least surprise, and none of the current watches and forks would actually want this to happen.

-Darius

On Thu, May 12, 2016 at 10:47 AM, Rich Magnuson rich.magnuson@villagereach.org wrote:

My preference, as non-tech committee member, is option 2. The code and intent of the reference distribution is incongruent with the current content of the open-lmis repo. The git history is of little value. I don’t think 50 watchers is a large enough of a community to worry about confusion. We can direct folks accordingly with text in the repo description and at the head of the README.

Rich

From: openlmis-dev@googlegroups.com [mailto:openlmis-dev@googlegroups.com] ** On Behalf Of **Josh Zamor

Sent: Tuesday, May 10, 2016 5:41 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Future of GitHub open-lmis repository?

As we continue to move forward with OpenLMIS v3 and the future of OpenLMIS being composed of multiple Independent Services, each within their own git repository, there is a question that the technical community should address pertaining to the future role of the open-lmis GitHub repository. This is under question as the bulk of the code within this repository will, in v3, be found within multiple Independent Services, and so by and large, open-lmis would be very lean in OpenLMIS v3.

There are two obvious options:

  1. The open-lmis repository continues into version 3 and beyond and becomes a lean repository. Meaning that most of the Java, Javascript, etc code which comprise its features is removed from the dev & master branches. In v3 and beyond it’ll hold container management code/scripts that defines the OpenLMIS Reference Distribution (that which composes the Services and other infrastructure). All v1 through v2 code is NOT purged from the git history and will continue to be accessible through tags and support branches for fixing bugs, etc.

  2. The open-lmis repository does not play a role in v3. OpenLMIS v1 and v2 will of course stay in open-lmis, however a new yet-to-be-named repository would be used for v3 code/scripts.

From my perspective, I think option 1 has the most consistency with the community. The pros would include maintaining a consistent git repository for all OpenLMIS versions. It would also keep our current repository stars (50), watches (53), forks (30) etc. The cons I think would primarily be that there would be a big commit that would remove most of the source code from the HEAD of dev and eventually master branches and that might look scary/weird.

Option 2’s big pro is that is avoids the scary / weird code “removal” commit. It would also provide a nice clean break and the git history would be small because the source would be small - meaning a fast git clone. It’s con however is that a new repository would be “the OpenLMIS” and the open-lmis repo would essentially become a legacy repo that only contained version 1 and 2.

I’ve stated my bias above and the pros / cons as I see them. That all said, I’m interested in your thoughts on options 1 or 2?

Ideally we could discuss here and the technical committee could make this decision here, however if we think we need to we can also put this on the next tech-call’s agenda. Please let me know this week as we do need to move forward rather soon.

Thanks!

Best,

Josh

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/fb6fd036-591c-4392-98bd-aa4686ceea5c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/BN1PR02MB0218D175D7BE5516538E90493730%40BN1PR02MB021.namprd02.prod.outlook.com.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R5LWYtYU%2BBRgt_hE2iYuSoWdSQRPOTw82ga13OSK0HKbw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

I would think that when you do a code rewrite you should do it in a new repository. So it’s different from the v1 to v2 switch, which was continued development.

For example:

AngularJS 1.x -> https://github.com/angular/angular.js
AngularJS 2.x -> https://github.com/angular/angular

Okay, maybe Angular is a questionable example, in the sense that many people dislike their 1->2 shift, but it’s actually a good analog for this: a rewrite in a new version, but there is still usage and development of the previous version while the new version is being developed.

-Darius

···

On Thu, May 12, 2016 at 5:28 PM, Josh Zamor josh.zamor@villagereach.org wrote:

I do think that redirection has its benefits. To me however if I came upon the result of option 2 I’d be surprised:

  1. the open-lmis repository in the OpenLMIS organization, wouldn’t have anything to do with future OpenLMIS versions. That seems counter-intuitive, even with a redirection message
  2. version changes and active development have always occurred in the open-lmis repository. Master and dev are always changing. Moving old code is what happens as development occurs. The jump from v1 to v2 was in the area of 6000 commits, thousands of new files and ~2 years apart. No one at the repository level was effected.
  3. v1 through v2 code is in the open-lmis repository. I can git checkout from one to the other quickly. Why shouldn’t the starting point of v3 be the same?

Good feedback, keep it coming.

Best,

Josh

On May 12, 2016, at 1:33 PM, Kevin Cussen kevin.cussen@villagereach.org wrote:

Hi all,

Not voting one way or the other, however, if we go the route of #2 why not put a note on the top of v2 readme stating that 2.0 is a deprecated version and linking to v3 for new deployments?

Cheers,

Kevin Cussen | kevin.cussen@villagereach.org

Manager, Information Systems

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: 1.206.604.4209 FAX: 1.206.860.6972

SKYPE: kevin.cussen.vr

www.villagereach.org

Connect on Facebook, Twitter** ** and our Blog


From: openlmis-dev@googlegroups.com <openlmis-dev@googlegroups.com > on behalf of Darius Jazayeri djazayer@thoughtworks.com

Sent: Thursday, May 12, 2016 12:45

To: Rich Magnuson

Cc: Josh Zamor; OpenLMIS Dev

Subject: Re: [openlmis-dev] Future of GitHub open-lmis repository?

I agree with Rich. Strong vote for #2.

Having the master branch of the existing repository suddenly delete all the files and become something completely different would violate the principle of least surprise, and none of the current watches and forks would actually want this to happen.

-Darius

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R5LWYtYU%2BBRgt_hE2iYuSoWdSQRPOTw82ga13OSK0HKbw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

On Thu, May 12, 2016 at 10:47 AM, Rich Magnuson rich.magnuson@villagereach.org wrote:

My preference, as non-tech committee member, is option 2. The code and intent of the reference distribution is incongruent with the current content of the open-lmis repo. The git history is of little value. I don’t think 50 watchers is a large enough of a community to worry about confusion. We can direct folks accordingly with text in the repo description and at the head of the README.

Rich

From: openlmis-dev@googlegroups.com [mailto:openlmis-dev@googlegroups.com] ** On Behalf Of **Josh Zamor

Sent: Tuesday, May 10, 2016 5:41 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Future of GitHub open-lmis repository?

As we continue to move forward with OpenLMIS v3 and the future of OpenLMIS being composed of multiple Independent Services, each within their own git repository, there is a question that the technical community should address pertaining to the future role of the open-lmis GitHub repository. This is under question as the bulk of the code within this repository will, in v3, be found within multiple Independent Services, and so by and large, open-lmis would be very lean in OpenLMIS v3.

There are two obvious options:

  1. The open-lmis repository continues into version 3 and beyond and becomes a lean repository. Meaning that most of the Java, Javascript, etc code which comprise its features is removed from the dev & master branches. In v3 and beyond it’ll hold container management code/scripts that defines the OpenLMIS Reference Distribution (that which composes the Services and other infrastructure). All v1 through v2 code is NOT purged from the git history and will continue to be accessible through tags and support branches for fixing bugs, etc.

  2. The open-lmis repository does not play a role in v3. OpenLMIS v1 and v2 will of course stay in open-lmis, however a new yet-to-be-named repository would be used for v3 code/scripts.

From my perspective, I think option 1 has the most consistency with the community. The pros would include maintaining a consistent git repository for all OpenLMIS versions. It would also keep our current repository stars (50), watches (53), forks (30) etc. The cons I think would primarily be that there would be a big commit that would remove most of the source code from the HEAD of dev and eventually master branches and that might look scary/weird.

Option 2’s big pro is that is avoids the scary / weird code “removal” commit. It would also provide a nice clean break and the git history would be small because the source would be small - meaning a fast git clone. It’s con however is that a new repository would be “the OpenLMIS” and the open-lmis repo would essentially become a legacy repo that only contained version 1 and 2.

I’ve stated my bias above and the pros / cons as I see them. That all said, I’m interested in your thoughts on options 1 or 2?

Ideally we could discuss here and the technical committee could make this decision here, however if we think we need to we can also put this on the next tech-call’s agenda. Please let me know this week as we do need to move forward rather soon.

Thanks!

Best,

Josh

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/fb6fd036-591c-4392-98bd-aa4686ceea5c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/BN1PR02MB0218D175D7BE5516538E90493730%40BN1PR02MB021.namprd02.prod.outlook.com.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

Any additional input on this topic, especially from the Tech Committee? It is something we need to decide very soon.

Thanks - Rich

···

I would think that when you do a code rewrite you should do it in a new repository. So it’s different from the v1 to v2 switch, which was continued development.

For example:

AngularJS 1.x -> https://github.com/angular/angular.js

AngularJS 2.x -> https://github.com/angular/angular

Okay, maybe Angular is a questionable example, in the sense that many people dislike their 1->2 shift, but it’s actually a good analog for this: a rewrite in a new version, but there is still usage and development of the previous version while the new version is being developed.

-Darius

On Thu, May 12, 2016 at 5:28 PM, Josh Zamor josh.zamor@villagereach.org wrote:

I do think that redirection has its benefits. To me however if I came upon the result of option 2 I’d be surprised:

  1. the open-lmis repository in the OpenLMIS organization, wouldn’t have anything to do with future OpenLMIS versions. That seems counter-intuitive, even with a redirection message
  1. version changes and active development have always occurred in the open-lmis repository. Master and dev are always changing. Moving old code is what happens as development occurs. The jump from v1 to v2 was in the area of 6000 commits, thousands of new files and ~2 years apart. No one at the repository level was effected.
  1. v1 through v2 code is in the open-lmis repository. I can git checkout from one to the other quickly. Why shouldn’t the starting point of v3 be the same?

Good feedback, keep it coming.

Best,

Josh

On May 12, 2016, at 1:33 PM, Kevin Cussen kevin.cussen@villagereach.org wrote:

Hi all,

Not voting one way or the other, however, if we go the route of #2 why not put a note on the top of v2 readme stating that 2.0 is a deprecated version and linking to v3 for new deployments?

Cheers,

Kevin Cussen | kevin.cussen@villagereach.org

Manager, Information Systems

Village****Reach* Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: 1.206.604.4209
FAX: 1.206.860.6972

SKYPE: kevin.cussen.vr

www.villagereach.org

Connect on Facebook, Twitter** ** and our Blog


From: openlmis-dev@googlegroups.com
openlmis-dev@googlegroups.com on behalf of Darius Jazayeri djazayer@thoughtworks.com

Sent: Thursday, May 12, 2016 12:45

To: Rich Magnuson

Cc: Josh Zamor; OpenLMIS Dev

Subject: Re: [openlmis-dev] Future of GitHub open-lmis repository?

I agree with Rich. Strong vote for #2.

Having the master branch of the existing repository suddenly delete all the files and become something completely different would violate the principle of least surprise, and none of the current watches and forks would actually want this to happen.

-Darius

On Thu, May 12, 2016 at 10:47 AM, Rich Magnuson rich.magnuson@villagereach.org wrote:

My preference, as non-tech committee member, is option 2. The code and intent of the reference distribution is incongruent with the current content of the open-lmis repo. The git history is of little value. I don’t think 50 watchers is a large enough of a community to worry about confusion. We can direct folks accordingly with text in the repo description and at the head of the README.

Rich

From: openlmis-dev@googlegroups.com [mailto:openlmis-dev@googlegroups.com] ** On Behalf Of **Josh Zamor

Sent: Tuesday, May 10, 2016 5:41 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Future of GitHub open-lmis repository?

As we continue to move forward with OpenLMIS v3 and the future of OpenLMIS being composed of multiple Independent Services, each within their own git repository, there is a question that the technical community should address pertaining to the future role of the open-lmis GitHub repository. This is under question as the bulk of the code within this repository will, in v3, be found within multiple Independent Services, and so by and large, open-lmis would be very lean in OpenLMIS v3.

There are two obvious options:

  1. The open-lmis repository continues into version 3 and beyond and becomes a lean repository. Meaning that most of the Java, Javascript, etc code which comprise its features is removed from the dev & master branches. In v3 and beyond it’ll hold container management code/scripts that defines the OpenLMIS Reference Distribution (that which composes the Services and other infrastructure). All v1 through v2 code is NOT purged from the git history and will continue to be accessible through tags and support branches for fixing bugs, etc.

  2. The open-lmis repository does not play a role in v3. OpenLMIS v1 and v2 will of course stay in open-lmis, however a new yet-to-be-named repository would be used for v3 code/scripts.

From my perspective, I think option 1 has the most consistency with the community. The pros would include maintaining a consistent git repository for all OpenLMIS versions. It would also keep our current repository stars (50), watches (53), forks (30) etc. The cons I think would primarily be that there would be a big commit that would remove most of the source code from the HEAD of dev and eventually master branches and that might look scary/weird.

Option 2’s big pro is that is avoids the scary / weird code “removal” commit. It would also provide a nice clean break and the git history would be small because the source would be small - meaning a fast git clone. It’s con however is that a new repository would be “the OpenLMIS” and the open-lmis repo would essentially become a legacy repo that only contained version 1 and 2.

I’ve stated my bias above and the pros / cons as I see them. That all said, I’m interested in your thoughts on options 1 or 2?

Ideally we could discuss here and the technical committee could make this decision here, however if we think we need to we can also put this on the next tech-call’s agenda. Please let me know this week as we do need to move forward rather soon.

Thanks!

Best,

Josh

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/fb6fd036-591c-4392-98bd-aa4686ceea5c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/BN1PR02MB0218D175D7BE5516538E90493730%40BN1PR02MB021.namprd02.prod.outlook.com.

For more options, visit https://groups.google.com/d/optout.

Darius Jazayeri* Principal Architect - Global Health*

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

ThoughtWorks

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R5LWYtYU%2BBRgt_hE2iYuSoWdSQRPOTw82ga13OSK0HKbw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Darius Jazayeri* Principal Architect - Global Health*

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

ThoughtWorks

Whatever ended up being decided on this question?

-Darius

···

On Wednesday, May 18, 2016 at 12:29:15 AM UTC-7, Rich Magnuson wrote:

Any additional input on this topic, especially from the Tech Committee? It is something we need to decide very soon.

Thanks - Rich

From: Darius Jazayeri [mailto:djaz...@thoughtworks.com]

Sent: Friday, May 13, 2016 4:51 AM

To: Josh Zamor josh....@villagereach.org

Cc: Kevin Cussen kevin....@villagereach.org; Rich Magnuson rich.m...@villagereach.org; OpenLMIS Dev openlm...@googlegroups.com

Subject: Re: [openlmis-dev] Future of GitHub open-lmis repository?

I would think that when you do a code rewrite you should do it in a new repository. So it’s different from the v1 to v2 switch, which was continued development.

For example:

AngularJS 1.x -> https://github.com/angular/angular.js

AngularJS 2.x -> https://github.com/angular/angular

Okay, maybe Angular is a questionable example, in the sense that many people dislike their 1->2 shift, but it’s actually a good analog for this: a rewrite in a new version, but there is still usage and development of the previous version while the new version is being developed.

-Darius

On Thu, May 12, 2016 at 5:28 PM, Josh Zamor josh....@villagereach.org wrote:

I do think that redirection has its benefits. To me however if I came upon the result of option 2 I’d be surprised:

  1. the open-lmis repository in the OpenLMIS organization, wouldn’t have anything to do with future OpenLMIS versions. That seems counter-intuitive, even with a redirection message
  2. version changes and active development have always occurred in the open-lmis repository. Master and dev are always changing. Moving old code is what happens as development occurs. The jump from v1 to v2 was in the area of 6000 commits, thousands of new files and ~2 years apart. No one at the repository level was effected.
  3. v1 through v2 code is in the open-lmis repository. I can git checkout from one to the other quickly. Why shouldn’t the starting point of v3 be the same?

Good feedback, keep it coming.

Best,

Josh

On May 12, 2016, at 1:33 PM, Kevin Cussen kevin....@villagereach.org wrote:

Hi all,

Not voting one way or the other, however, if we go the route of #2 why not put a note on the top of v2 readme stating that 2.0 is a deprecated version and linking to v3 for new deployments?

Cheers,

Kevin Cussen | kevin....@villagereach.org

Manager, Information Systems

Village****Reach* Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: 1.206.604.4209
FAX: 1.206.860.6972

SKYPE: kevin.cussen.vr

www.villagereach.org

Connect on Facebook, Twitter** ** and our Blog


From: openlm...@googlegroups.com
openlm...@googlegroups.com on behalf of Darius Jazayeri djaz...@thoughtworks.com

Sent: Thursday, May 12, 2016 12:45

To: Rich Magnuson

Cc: Josh Zamor; OpenLMIS Dev

Subject: Re: [openlmis-dev] Future of GitHub open-lmis repository?

I agree with Rich. Strong vote for #2.

Having the master branch of the existing repository suddenly delete all the files and become something completely different would violate the principle of least surprise, and none of the current watches and forks would actually want this to happen.

-Darius

On Thu, May 12, 2016 at 10:47 AM, Rich Magnuson rich.m...@villagereach.org wrote:

My preference, as non-tech committee member, is option 2. The code and intent of the reference distribution is incongruent with the current content of the open-lmis repo. The git history is of little value. I don’t think 50 watchers is a large enough of a community to worry about confusion. We can direct folks accordingly with text in the repo description and at the head of the README.

Rich

From: openlm...@googlegroups.com [mailto:openlmis-dev@googlegroups.com] ** On Behalf Of **Josh Zamor

Sent: Tuesday, May 10, 2016 5:41 PM

To: OpenLMIS Dev openlm...@googlegroups.com

Subject: [openlmis-dev] Future of GitHub open-lmis repository?

As we continue to move forward with OpenLMIS v3 and the future of OpenLMIS being composed of multiple Independent Services, each within their own git repository, there is a question that the technical community should address pertaining to the future role of the open-lmis GitHub repository. This is under question as the bulk of the code within this repository will, in v3, be found within multiple Independent Services, and so by and large, open-lmis would be very lean in OpenLMIS v3.

There are two obvious options:

  1. The open-lmis repository continues into version 3 and beyond and becomes a lean repository. Meaning that most of the Java, Javascript, etc code which comprise its features is removed from the dev & master branches. In v3 and beyond it’ll hold container management code/scripts that defines the OpenLMIS Reference Distribution (that which composes the Services and other infrastructure). All v1 through v2 code is NOT purged from the git history and will continue to be accessible through tags and support branches for fixing bugs, etc.

  2. The open-lmis repository does not play a role in v3. OpenLMIS v1 and v2 will of course stay in open-lmis, however a new yet-to-be-named repository would be used for v3 code/scripts.

From my perspective, I think option 1 has the most consistency with the community. The pros would include maintaining a consistent git repository for all OpenLMIS versions. It would also keep our current repository stars (50), watches (53), forks (30) etc. The cons I think would primarily be that there would be a big commit that would remove most of the source code from the HEAD of dev and eventually master branches and that might look scary/weird.

Option 2’s big pro is that is avoids the scary / weird code “removal” commit. It would also provide a nice clean break and the git history would be small because the source would be small - meaning a fast git clone. It’s con however is that a new repository would be “the OpenLMIS” and the open-lmis repo would essentially become a legacy repo that only contained version 1 and 2.

I’ve stated my bias above and the pros / cons as I see them. That all said, I’m interested in your thoughts on options 1 or 2?

Ideally we could discuss here and the technical committee could make this decision here, however if we think we need to we can also put this on the next tech-call’s agenda. Please let me know this week as we do need to move forward rather soon.

Thanks!

Best,

Josh

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/fb6fd036-591c-4392-98bd-aa4686ceea5c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/BN1PR02MB0218D175D7BE5516538E90493730%40BN1PR02MB021.namprd02.prod.outlook.com.

For more options, visit https://groups.google.com/d/optout.

Darius Jazayeri* Principal Architect - Global Health*

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

ThoughtWorks

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R5LWYtYU%2BBRgt_hE2iYuSoWdSQRPOTw82ga13OSK0HKbw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Darius Jazayeri* Principal Architect - Global Health*

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

ThoughtWorks

At a
recent tech committee call
, the group decided on the new repository option, resulting in openlmis-blue.

···

Whatever ended up being decided on this question?

-Darius