Future of GitHub open-lmis repository?

[Josh Zamor]

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

[Rich Magnuson]

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

--
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.

[Darius Jazayeri]

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

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

djaz...@thoughtworks.com

Telephone

+1 617 383 9369

[Kevin Cussen]

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

 

VillageReach 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?

 

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

[Josh Zamor]

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

[Darius Jazayeri]

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

[Rich Magnuson]

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

 

Thanks - Rich

[djazayer]

Whatever ended up being decided on this question?

-Darius

[Rich Magnuson]

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

 

From: openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of djazayer
Sent: Tuesday, July 19, 2016 3:27 PM
To: OpenLMIS Dev <openlm...@googlegroups.com>
Cc: djaz...@thoughtworks.com; Josh Zamor <josh....@villagereach.org>; eli...@gmail.com; jxi...@thoughtworks.com; Kevin Cussen <kevin....@villagereach.org>
Subject: Re: [openlmis-dev] Future of GitHub open-lmis repository?

 

Whatever ended up being decided on this question?

 

-Darius