Contributions and Release Schedule

29 views
Skip to first unread message

Ben Leibert

unread,
Dec 1, 2017, 2:44:22 PM12/1/17
to OpenLMIS Dev

Hi everyone,

 

I’m under the impression that the next OpenLMIS release may not be for several months. Simultaneously, stakeholders in Malawi are willing to pay for small improvements which are probably globally applicable. I think it would be less than ideal, and counter to the fundamental cadence of agile development, to require stakeholders to wait for the next Core release to benefit from such features.

 

If an implementer is willing to take on the risk of using untested and unreleased code in certain cases, is there any reason not to:

 

1) Fork one or more of core’s services.

2) Change the serviceVersions to something like 1.0.0-CORE-SNAPSHOT-TAKEN-ON-[Current-Date].

3) Take care to leave everything else in the forked repositories as-is.

4) Create and use the resultant images.

 

Whenever possible, I understand that it would be better to avoid this. I’m also a bit concerned, though, about implementers being dependent on another team to create releases. Assuming an implementer is dedicated to the concept of contribution to Core, is there a better way to remove the release-related coupling that naturally follows?

 

Thank you,

Ben

Paweł Gesek

unread,
Dec 7, 2017, 10:06:43 AM12/7/17
to OpenLMIS Dev, Ben Leibert
The problem with forks is that they always tend to drift away from core and the cost of keeping up with latest core becomes higher and higher. However they happen due to many reasons (core not delivering needed releases, core contribution costs being too high, keeping up with core releases costing too much, forking costing less than adhering to a 'proper' method of extending, etc.). While we should not encourage forking, we will be faced with implementers doing it or seriously considering it due to the reasons mentioned.

I've been thinking lately on independently releasing the components, which could alleviate some of these issues to an extent. We could stabilize some parts and make them easier for implementers to extend/upgrade them (and start treating new major versions for them as a big deal)? Currently while our services/UI components have their own versions, semantically versioned, what really is the benefit of that if we are (almost always) releasing them as one ref-distro? Do implementers like Malawi even care what their component versions are currently or do are they only interested in the ref-distro version? I know that letting each service go on it's own with versions has it's drawbacks and will require us to start tracking dependencies between services, but it is something that I've been recently thinking about from time to time. Many people probably have opinions on this, so I am looking forward to hearing them.

Regards,
Paweł

   

--
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 openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/2958bd8a-49f0-4d64-b87f-436f6febbf70%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

Paweł Gesek
 Technical Project Manager
pge...@soldevelo.com / +48 690 020 875



SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

Josh Zamor

unread,
Dec 7, 2017, 11:00:11 AM12/7/17
to Paweł Gesek, OpenLMIS Dev, Ben Leibert
Absolutely agreed Pawel.  The intention is to release each service independently - the mechanisms, the testing, etc is all there already.  It has been my/our strong goal, and where we’re falling short is in automated testing - we have a good quantity of it, however our suite still has a couple gaps we need to close.  These gaps are the primary reason for doing such a formal regression testing cycle of the entire set of reference Services prior to recommending implementations adopting the released components.  After all there isn’t much in the ref distro that isn’t simply the released components - functionally.

Ben I’m actually surprised you’re asking about an implementation managed fork of a Service, so I’m guessing that this is coming from a desire to see a formal written statement about it.  I’d first encourage you to familiarize yourself with the Re-architecture Concept Note, specifically the section on “Challenge to Address”.  After you’ve read that if you still think we need a more detailed or more accessible documentation on the reasoning behind discouraging implementation managed forks, please let me know.  We’ve been down this road and OpenLMIS v3 is the answer - in short implementation managed forks work directly against our vision of shared benefit.  And shared benefit is why we’re all here.

Getting back to releasing each service - that’s something that can still be done and I’d encourage us to keep doing as frequently as possible.  Taking a single Service release, Implementers don’t get the benefits of full manual regression testing of the Ref Distro (only the set of Services in the Ref Distro’s “recipe” for a distribution does that), however they’d certainly be getting more quality than if they attempted to fork and maintain their own version of an OpenLMIS Service.

The last thing I’d like you to recognize Ben from the implementer perspective is the relationship between the Reference UI and the Independent Service releases.  When an implementation consider’s taking a release of a Service, any regressions that occur in an implementation need to consider that the root cause of such a regression may be any extensions they’ve made, or upgrades that they’d need of the Reference UI.  While it’d be nice to say that the Reference UI and a Service could all be rolled as one release, the architecture is not that, and we don’t want that - it increases unwanted technical coupling.  We can role stable releases of a Service, and after a full regression testing cycle we can also roll a release of all the Services and the Reference UI (i.e. the Ref Distro), however we can’t roll a release of a single Service and the Reference UI.  The intention of the Reference UI is of course evident in its name, it’s a reference for implementers to take, fork and customize (branding, etc).  Regressions can seem to appear when we forget that a Service release is more independent than a release of that UI which is intended to be a reference point for implementers to start from.  

We’re working on providing tools which help us and implementers evaluate their specific recipes of deployed Services and UI.  Most notably is the work on end to end (E2E) testing that I need to finish my initial work on.  I’ve been busy with the GDHF conference however once we have an E2E tool, I suspect we’ll have a start at helping the core software as well as implementers have an automated tool that can help evaluate their specific combination/recipe of Services and UI.  Once my initial work is done, I’ll be most interested in getting your help Ben for figuring out how implementations can adopt and extend the E2E testing tools to cover implementation specific features/scenarios.

Best,
Josh 


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.
Message has been deleted

Ben Leibert

unread,
Dec 7, 2017, 1:29:22 PM12/7/17
to OpenLMIS Dev
Hi Josh and Pawel,

Thank you both very much for your thoughtful responses. 

I realize that forking is a charged issue within the OpenLMIS community, and am familiar with the history described in the Re-architecture Concept Note. My intent isn’t to evoke a formal statement from the community that it’s been burned by forking and thus discourages it. Rather, my hope is to highlight what I perceive as a problem and elicit ideas for addressing it. 

At the moment, when implementers who wish to contribute to or benefit from changes within Core find it necessary to create a country-specific release, they’re left with only one community-approved option: to wait for the next Core release. I don’t think, however, that this degree of coupling is desirable for Core nor viable for implementations.

The issue for Core: Rolling a release whenever an implementation happens to need one places considerable burden on the Core team. Supporting Malawi this way has affected Core feature development, and the overhead will only grow as more implementation projects begin. It’s partly out of recognition of this overhead that the Core team indicated that the next full release may not be for another three months.

The issue for implementations: Being wholly dependent on an external team (that’s potentially within an independent organization) to be able to create and deliver releases of one’s own is risky. For organizations with whom we've historically had poor relations, it may even be unacceptable. There will likely be times when an implementer will need to commit their own resources to additional testing rather than wait for the Core team to do so as part of their own release. How often this happens will depend on the frequency of Core’s releases - an issue described in the last paragraph. 

Use of automation to increase the frequency of individual service releases would surely help to a large degree. Nevertheless, because I think my original idea was misunderstood, I think it needs restatement, so here goes:

I see value in allowing implementers the flexibility to create and use images based on any desired commit within the Core repositories. There’s risk to doing so – that’s understood. If an implementer is willing to accept the risk, however, how best can they achieve this aim? The most obvious option is for an implementer to create forks which they’d use exclusively for the purposes of creating docker images. No code change would be made within the forks, and they would therefore contribute nothing toward code/community fragmentation. Although this seems like a technically viable approach, it’s also inelegant. Can we do better? 

Thank you,
Ben
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-de...@googlegroups.com.
To post to this group, send email to openl...@googlegroups.com.



--

Paweł Gesek
Technical Project Manager
pge...@soldevelo.com / +48 690 020 875



SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

--
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 openl...@googlegroups.com.

Josh Zamor

unread,
Dec 7, 2017, 2:41:32 PM12/7/17
to Ben Leibert, OpenLMIS Dev
Thanks for the well written response Ben.

I’m going to keep this short since you’re familiar with the concept note and the context:

  • Forking and maintaining your own image of an unchanged set of code, yet unreleased Service, is like sleeping in a room in a building under construction.  You’d be better served asking the construction crew to finish the room that you’re going to sleep in, while the rest of the building construction goes on.  It’s safer and frankly more sane, when the alternative is neither.  Ben, you want to help us identify component releases that are useful, as you’ve been doing, rather than trying to release someone else’s Service.
  • The release process we have now is what Malawi wants.  I know they wouldn’t accept a looser release process.  Certainly not one where there’s no release process.

Thanks for the thoughts and when you’re ready to help with the implementer perspective on E2E testing please let me know.

Best,
Josh




Message has been deleted

Ben Leibert

unread,
Dec 7, 2017, 5:27:04 PM12/7/17
to OpenLMIS Dev
Hi Josh,

Thank you yet again for your thoughtful responses. I especially enjoy and admire your construction analogy. If I can respond to each of your bullet points respectively: 

* I’ve perceived clear release-fatigue from the Core team over the past month or so. It recently published a draft approach for releasing individual services, though. If this allows the Core team to sustain and scale the high level of responsiveness that Malawi has enjoyed to date, my concerns will mostly have been addressed.

* The full-release process is a great one. It especially offers value when numerous changes have been made since the previous full-release. As demonstrated by the need for the draft approach, however, there’s clearly a need sometimes for a lightweight and flexible alternative.

I’m curious about the E2E testing and look forward to delving in.

Kind regards,
Ben

Nick Reid

unread,
Dec 7, 2017, 5:44:59 PM12/7/17
to Josh Zamor, Ben Leibert, OpenLMIS Dev

So, I'm trying to follow this thread, and:

- I'm a little lost in what Ben is asking for (please be concrete)

- I like Josh's metaphor about moving into a building under construction


This discussion then got into "forking," which sounds like the nuclear option we are all trying to avoid. I'm not sure why we are talking about it.


What it sounds like Ben is asking for is to be able to pick up component releases as they are available. There seems to be a clear need to pick up a new version of a service, and a "matching" version of that service's UI.


The Reference-UI, like the Ref-Distro, just pulls together other docker-images. The large difference is that the Reference-UI currently contains code to register the UI to Consul (which we have plans to remove, FYI).


There is no reason an implementer shouldn't be able to pick up a component release of an OpenLMIS Service or UI Module. This does assume the implementer is "OK" that the component has not gone through a full regression test (ie there might be bugs - its like picking up a free mattress off the street).


The problem with OpenLMIS doing component releases, is that our product development process is focused on building a monolith - not individual components. The changes that we introduce to the individual repositories are not focused on making a single component stable, and then getting that section released.


If we as a community want to build a modular architecture we have to support the releases of components. The needs for a modular architecture seems to be well outlined in the Re-Architecture concept note (which I never read before, BTW). 


My opinion on this, is that technically we could support this process, but to actually achieve this - both the governance and product committees have to back it and provide funding to make it a priority for developers.


PS: None of this was meant to hurt anyone's feelings. I'm just trying to be direct.


-- nick --



Nick Reid | nick...@villagereach.org
Software Developer, Information Systems Group


VillageReach Starting at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org


From: openlm...@googlegroups.com <openlm...@googlegroups.com> on behalf of Josh Zamor <josh....@villagereach.org>
Sent: Thursday, December 7, 2017 11:41:28 AM
To: Ben Leibert
Cc: OpenLMIS Dev
Subject: Re: [openlmis-dev] Contributions and Release Schedule
 

Ben Leibert

unread,
Dec 7, 2017, 7:27:26 PM12/7/17
to Nick Reid, Josh Zamor, OpenLMIS Dev
Hi Nick,

Thank you very much for chiming in.

To be more concrete: I'm asking for a way in which an informed implementer can use an arbitrary version of a service without waiting long (perhaps a week at most) for an official Core release.

I use the term informed implementer because I don't see their role as that of a passive tenant amidst a bewildering array of construction. Instead, I see them as a real-estate agent trying to do some paint work but stymied by a couple of nails that need to first be banged into place. The room they care about is basically complete - a release was rolled just days ago and the condo is already on the market! Prospective buyers are coming tomorrow, though, and there isn't much time to wait for MegaCorp, the parent contractor, to get around to prioritizing this one little condo.

This thread's discussion has tended toward assurance that automated testing and individual service releases will allow the Core team to be responsive to all its implementors. The Core team is a great one, and I'm happy to take it at its word. I think you're right to have said though, Nick, that historically the "product development process [was] focused on building a monolith." There's room and value for that - but also a need to provide implementers with access to fixes made within individual services quickly and easily.

As a semi-aside, I'll mention that use of forks as I've consistently described in this thread shouldn't be seen as a "nuclear option." Like every technology, forks can be used to good or bad affect. VillageReach has been scarred by them in the past, but we'd always do well to keep an open mind. The use of forking I described involves no code modification and thus little if any of the downside we've previously encountered.

I recognize that it's easier, safer, and probably thus better to push the blanket message that all forks are simply unwelcome. To allow implementors to forgo such a free and easily available option, however, I think the Core team will will have to deliver admirably well on its promise to quickly provide service releases whenever asked. If the Core team commits to doing so, I'm confident they can.

Thanks again,
Ben

Nick Reid

unread,
Dec 7, 2017, 7:39:43 PM12/7/17
to Ben Leibert, OpenLMIS Dev

I'm loving that this condo metaphor is taking on a life of its own....


To be more concrete: I'm asking for a way in which an informed implementer can use an arbitrary version of a service without waiting long (perhaps a week at most) for an official Core release.


Questions:
- Does "arbitrary version" mean a stable version of a service? (ie not a SNAPSHOT)
- What would block an implementer from picking up a released service?
- Is there a specific set of bugs or "features" that you (Ben) would like to see released?
^^ That is really what I meant by concrete

A larger question: How does core prioritize bugs/features for implementers?

In our working process so far it seems like "the squeaky wheel gets the grease," but that will get contentious (at best) once there are multiple implementations.



Nick Reid | nick...@villagereach.org
Software Developer, Information Systems Group


VillageReach Starting at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org


From: openlm...@googlegroups.com <openlm...@googlegroups.com> on behalf of Ben Leibert <benle...@gmail.com>
Sent: Thursday, December 7, 2017 4:27:19 PM
To: Nick Reid
Cc: Josh Zamor; OpenLMIS Dev

Paweł Gesek

unread,
Dec 8, 2017, 11:46:21 AM12/8/17
to OpenLMIS Dev
I agree with Nick, that if we want components to live on their own and do component releases independent from each other, we will also have to stop developing OpenLMIS as a monolith and focus more on services. One problem I see with this is the boundaries between components not being evidently clear to people not intimate with the code, i.e. where do requisitions end and fulfillment begins? Or requisitions and stock management?

One thing blocking implementers I see and have to mention is the frequency of major releases we do, especially with services like reference data. If implementers are to pick up these releases, they must be confident things won't start falling apart for them. With major versions there also is no guarantee old UI versions will continue to work (and major versions in reference data affect everything). In order to do this will have to finalize our rest patterns and fix lingering issues like the lack of pagination on some endpoints (I don't think we ever got to do the pagination big bang in reference data we considered and voted for a while back).

As far as committing to a frequent release cycle for components - I think the process could use some more automation, but I think that in order to get there the key is the whole community committing to it. 

Regards,
Paweł

On Fri, Dec 8, 2017 at 1:39 AM, Nick Reid <nick...@villagereach.org> wrote:

I'm loving that this condo metaphor is taking on a life of its own....


To be more concrete: I'm asking for a way in which an informed implementer can use an arbitrary version of a service without waiting long (perhaps a week at most) for an official Core release.


 Questions:
- Does "arbitrary version" mean a stable version of a service? (ie not a SNAPSHOT)
- What would block an implementer from picking up a released service?
- Is there a specific set of bugs or "features" that you (Ben) would like to see released?
^^ That is really what I meant by concrete

A larger question: How does core prioritize bugs/features for implementers?

In our working process so far it seems like "the squeaky wheel gets the grease," but that will get contentious (at best) once there are multiple implementations.

Software Developer, Information Systems Group

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
--
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.

--
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 openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/5A29DC67.1010907%40gmail.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 openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CY4PR02MB2199EA2CB167A0A00FE9A56994300%40CY4PR02MB2199.namprd02.prod.outlook.com.

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



--

Paweł Gesek
 Technical Project Manager
pge...@soldevelo.com / +48 690 020 875

Josh Zamor

unread,
Dec 11, 2017, 5:25:55 PM12/11/17
to OpenLMIS Dev
I agree with Nick, that if we want components to live on their own and do component releases independent from each other, we will also have to stop developing OpenLMIS as a monolith and focus more on services. One problem I see with this is the boundaries between components not being evidently clear to people not intimate with the code, i.e. where do requisitions end and fulfillment begins? Or requisitions and stock management?

Thanks for this Pawel.  What I'm hearing is that the development team is actually unclear about the boundaries of each service / domain.  I thought we actually were all pretty clear about the role of Stock Management as opposed to Requisitions, but perhaps we need some more formal diagrams, descriptions and use-case statements?  What are the ways that you think would best serve our current developer community as well as on-boarding newcomers?

One thing blocking implementers I see and have to mention is the frequency of major releases we do, especially with services like reference data.

Also agreed Pawel.  We do a number of major version releases as we're iterating quickly on our API - trying to get to the more right REST resources quicker.  Perhaps now is the right time to start slowing down our breaking API changes, however I'm concerned with what we'll have to live with if we do that now.  We still have few external clients, so now's the time to iterate and break things.  Thoughts?

As a semi-aside, I'll mention that use of forks as I've consistently described in this thread shouldn't be seen as a "nuclear option." Like every technology, forks can be used to good or bad affect. VillageReach has been scarred by them in the past, but we'd always do well to keep an open mind. The use of forking I described involves no code modification and thus little if any of the downside we've previously encountered.

I recognize that it's easier, safer, and probably thus better to push the blanket message that all forks are simply unwelcome. To allow implementors to forgo such a free and easily available option, however, I think the Core team will will have to deliver admirably well on its promise to quickly provide service releases whenever asked. If the Core team commits to doing so, I'm confident they can.

Ben I can't let this go.  I have to point out to you that you're not talking about forks, you're talking about subverting the OpenLMIS release process.  While yes the actual fork is what you're talking about, the overall approach you're talking about here is to bypass our release process.  While I can appreciate your concern for the core team, I can not recommend to any implementer or user that they should bypass the release process.  I do think there's room for improvement in documenting and making clear the release process, which brings me to where you could assist:  provide feedback on our release process documentation - specifically how an implementer can stay engaged.
 

Thanks all,  this has been a weird thread but I appreciate some of the topics that came out.

Best,
Josh

Ben Leibert

unread,
Dec 11, 2017, 11:00:26 PM12/11/17
to OpenLMIS Dev
Also agreed Pawel.  We do a number of major version releases as we're iterating quickly on our API - trying to get to the more right REST resources quicker.  Perhaps now is the right time to start slowing down our breaking API changes, however I'm concerned with what we'll have to live with if we do that now.  We still have few external clients, so now's the time to iterate and break things.  Thoughts?

Iterating on the API as much as possible before additional implementations adopt it makes sense to me.

Ben I can't let this go.  I have to point out to you that you're not talking about forks, you're talking about subverting the OpenLMIS release process.  While yes the actual fork is what you're talking about, the overall approach you're talking about here is to bypass our release process.  While I can appreciate your concern for the core team, I can not recommend to any implementer or user that they should bypass the release process.  

You’re exactly right that my concern relates to the release process rather than forking. My main aim has been to point out that:

1. A leisurely release schedule will leave implementers feeling blocked.
2. The natural response to this impediment will be to consider forking.
3. Solicit ideas for any options better than #2 above.

The thread's response has essentially been that automation and timely component-releases will soon address part #1, and thereby parts 2 and 3 as well. I'm happy with that approach if folks feel it's viable. I'd only want to emphasize its importance. Just as code extensibility allows implementers to develop without forking, responsive Core releases will allow implementers to deploy without forking.

Kind regards,
Ben


Paweł Gesek

unread,
Dec 12, 2017, 4:07:23 AM12/12/17
to Ben Leibert, OpenLMIS Dev
Thanks for this Pawel.  What I'm hearing is that the development team is actually unclear about the boundaries of each service / domain.  I thought we actually were all pretty clear about the role of Stock Management as opposed to Requisitions, but perhaps we need some more formal diagrams, descriptions and use-case statements?  What are the ways that you think would best serve our current developer community as well as on-boarding newcomers?

What I am saying is that there might be a communication gap between the business (product committee, implementers, etc.) and the dev team. For example the business will say that they want to focus on 'orders'. This might mean they want to work on the fulfilment service, but it might also mean that they want to work on the convert to order functionality in requisitions. Or possibly both. It is also possible that most of the changes will be done to the supply chain domain that lives in reference data. So it might not be evidently clear what releases will have to be done for a given feature - will it be one service, two services, three services? Which change will be minor, which one major? 

I don't think it's an issue that will be hard to overcome, but I think that we will have to start giving this some thought.

Thanks,
Paweł

--
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 openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/92a798ef-c2b0-4065-95aa-50559fbdcc5f%40googlegroups.com.

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



--

Paweł Gesek
 Technical Project Manager
pge...@soldevelo.com / +48 690 020 875

Ben Leibert

unread,
Dec 12, 2017, 12:32:55 PM12/12/17
to OpenLMIS Dev
Hi Paweł,

That's interesting - I considered starting this thread on the Product rather than Tech committee forum because the potential communication gap between developers and the business community is one of its underlying concerns. Since day one, business users have been told about various contribution models. They've been formally defined, the Core team has committed to supporting them (via extension points, for example), and the benefits of coupling (contributing) one's code to Core have been well advertised. The release process seems to have been given none of this attention however. Ironically, it's an issue business users care about much more because their ultimate concern is the deployment of a working product.

So, at present, implementers are asked to accept dependency on a Core release schedule which, as far as I know, is only vaguely defined. There's no guarantee of a component release soon after a severe bug has been found and fixed, for instance. We've done a great job of defining a release process, but I've seen much less about release schedules. Implementers are thus left to wait and wonder - and consider their alternatives.

I think that some of this can be addressed by communication (closing the "gap," as you put it Paweł). Some of it can also be remedied by commitment. I'd hope that we can commit to and then communicate something like this:

A) Implementers - please recognize and accept reliance on the Core team for component and reference-releases.

B) In return, the Core team will commit to releasing reference-distributions every (fill in the blank) and individual components when (fill in the blank... ideally whenever severe bugs have been fixed).

Kind regards,
Ben
 

 

Josh Zamor

unread,
Dec 12, 2017, 8:08:54 PM12/12/17
to OpenLMIS Dev
Lets not forget where you started this Ben:


1) Fork one or more of core’s services.

2) Change the serviceVersions to something like 1.0.0-CORE-SNAPSHOT-TAKEN-ON-[Current-Date].

3) Take care to leave everything else in the forked repositories as-is.

4) Create and use the resultant images.


This is a very different sort of question than the one you're asking now:

There's no guarantee of a component release soon after a severe bug has been found and fixed, for instance. We've done a great job of defining a release process, but I've seen much less about release schedules. Implementers are thus left to wait and wonder - and consider their alternatives.

I'm starting to think that I now know the direction of what it is you're asking, however I've had to guess at this.  Hopefully this is closer.

On schedules I believe you're aware we're targeting the Ref Distro v3.3 release in the first quarter of 2018:  https://openlmis.atlassian.net/wiki/x/CIAdAg  (the timeline already is updated).

On patching, you're correct there's no current guarantee - we haven't worked on the infrastructure for that yet.  I'd bring your attention to this bit of build infrastructure that's marked critical and already planned for that release:  https://openlmis.atlassian.net/browse/OLMIS-3498

You do have a significant amount of information - the next Ref Distro release is Q1 of 2018 and as part of that we're aiming to put into place the ability to patch some (scope TBD) released components - going forward from that release.  Between now and then what will help you greatly is to get your requests/priorities for that release into our backlog.  Perhaps you already have that and can share?

As far as what we'll discuss here in the technical committee, I think you have your answer.  Do not subvert the release process.  I hope you understand how you can be apart of that release planning: 
  • If you're asking to change the current Ref Distro release schedule you'll need to go to product committee. 
  • If you'd like to propose a single Service be released ahead of that schedule, you're more than welcome to propose what the Service release would be here in the Technical Committee.  Specifics are going to help a great deal.

...on the Product rather than Tech committee forum because the potential communication gap between developers and the business community is one of its underlying concerns... The release process seems to have been given none of this attention however. Ironically, it's an issue business users care about much more because their ultimate concern is the deployment of a working product.

This concerns me as I don't believe this gap exists generally. Rather I don't think you've made clear what you'd propose as the next release of any of the Services.  The Ref Distro release schedule and general scope you should know.  There is no current plan to release any other Service ahead of that schedule unless someone here makes a case and a plan for how to accomplish that.  Without that I again have to re-iterate and advise you:
  • Do not subvert the release process. 
And I'd encourage:
  • Participate here in this community of developers to work toward specific Service releases.

Best,
Josh
Message has been deleted

Ben Leibert

unread,
Dec 13, 2017, 12:23:39 AM12/13/17
to OpenLMIS Dev
Lets not forget where you started this Ben:
1) Fork one or more of core’s services.
2) Change the serviceVersions to something like 1.0.0-CORE-SNAPSHOT-TAKEN-ON-[Current-Date].
3) Take care to leave everything else in the forked repositories as-is.
4) Create and use the resultant images.
 
This is a very different sort of question than the one you're asking now:
There's no guarantee of a component release soon after a severe bug has been found and fixed, for instance. We've done a great job of defining a release process, but I've seen much less about release schedules. Implementers are thus left to wait and wonder - and consider their alternatives.


Hi Josh,

I'm sorry to have been unclear. Steps 1 through 4 in my initial message are exactly what I had in mind when later writing that implementers currently have incentive to "consider their alternatives." The question/concern is one and the same... but obviously hasn't been expressed well enough. Because I've already tried restating the concern within this thread, I don't think doing so again would likely be helpful. Instead, I propose taking a few minutes during any upcoming meeting already on the docket to give it a try verbally. 

In the meanwhile, I should highlight that the Core team has done a truly good job of supporting Malawi. The concern I've voiced certainly shouldn't be taken to suggest otherwise.

Kind regards,
Ben
Reply all
Reply to author
Forward
0 new messages