Release Process Standardization Ideas

maurya · November 13, 2015, 2:06am

Standardization of the Release process is needed as the current process has not been effective enough and has been causing a lot of friction and pressure on the people involved

Based on a recent design call on Release standardization(Nov 4th, 2015) attended by @wyclif, @dkayiwa and myself, I present a few ideas discussed: This is a continuation to this talk post

Please reply to this topic with your opinion on if you support or do not support the list items below. If you have any better Ideas please do mention them as well.

1. Decide on the Release timeline - Starting with a timeline for the Reference Application - @dkayiwa and @wyclif Agreed Before agreeing to this idea please consider the process, pro’s and con’s for this model of release Process:

Early January: Select release manager for September release. March release manager announces modules. Mid January: Code freeze for March release. Code freeze refers to branching into a release branch which will not accept any new pull requests.(unless some bug discovered in UAT or some code breaking bug is discovered). The normal pull request still get accepted in the master branch of the code **Early February:**Release all required modules for March release. Mid February: Set up UAT for March release Early March: Address any issues from UAT for March release Early June: September release manager announces modules. July: Select release manager for next March release. Code freeze for September release. Early August: Release all required modules for September release. Mid August: Set up UAT for September release. Early September: address any issues from UAT for September release.

Pros: a. Gives ample time for module owners to release the modules. b. Gives ample time to perform User Acceptance Testing c. Gives ample time to address any issues from UAT. d. Gives ample time for the Release Manager (Generally a new Volunteer) to understand the release process and setup the required e. Have standard release dates for our releases. f. Need not worry about someone committing/accepting a pull request that will delay the release. Will have a release ready stage for the modules.

Cons: a. Have to change our CI release process to release off of the release branch (Not sure how difficult this is @cintiadr might have more knowledge ) b. Will create an extra step of creating/managing a branch, though it might be of minimal load this can either be taken up by module owners or the release manager. c. If any bug is discovered in the UAT, the fix has to be implemented in both the release and the master branch.

2. Make Release Process information more transparent: Release roadmap Pages for the Platform and the Reference Application created when the release manager is chosen (that will transform into Release pages)

The actual tickets in each module that are being included in the Reference Application or the Platform are not visible for the general public to view in the technical roadmap. Presently - An implementer needs to go to JIRA and search in each Module which ticket is being included. A simple inclusion of Jira Tickets as shown in Getting Started as a Developer Page would be fine.

This will allow implementers to understand the Overview/status of features and issues being solved/included in the release. And Interested implementers will be able to push the tickets they want to get included in the release.

3. Include Implementers more in the Release Roadmap: Decide the process of getting features/issues into the release roadmap, this will allow implementers and developers to understand the process and have a say in the release

@wyclif - Presently they are decided on a design call / Developer Call. Darius or Burke say this should be in a specific version, if not done in one version they are bumped to the next version. @dkayiwa - Majority of tickets are decided by the release manager and for grey tickets they are talked about in a Design Call @wyclif - Voting has been used for dev swimlane, and we ignored it recently.

There is a voting system available in the JIRA. Select tickets with highest number of votes and showcase them in the release roadmap page.This will make the process more transparent.

This will allow implementers to go to JIRA and vote for the features/issues they are most interested in. @dkayiwa and @wyclif agreed.

4. Decide on a way to communicate with the interested stakeholders: After people voting on a JIRA ticket or mentioning that they are interested to get a feature included in OpenMRS people have not got a proper response about the status of the Features/Issues. To handle this if we have a release roadmap that should solve the problem of knowing the status. But if their issues are not being included the release manager should send out a mail/ Announce in a talk post about why their ticket is not being included or in which release version it would be included.

5. Decide on a way to best showcase download statistics present in sourceforge, they can act as a great metrics - Sourceforge Download statistics - has great data like the number of times each version has been downloaded and their total( 250,000+ total downloads) and how many countries downloaded it (200+ countries and territories) Though this is not something that would interest the implementers it would definitely allow people new to OpenMRS understand its impact.

This is not something to replace the Atlas module information as that is definitely more accurate and a better metric of the impact of OpenMRS implementations. But, OpenMRS is not just used for Implementation, it is used in many different ways, though we do not have a way to know that now we at least know the quantitative impact.

Presently I’m including them as a link in the wiki under releases like here. I’m not sure if that is the best way to showcase it though.

They provide an API to extract the data, may be this can be integrated in the wiki or a metrics module. @dkayiwa - Atlas is the most realistic, but we need both

6. Platform Release Process Improvements @wyclif - Most of the process included in this release process page can be automated through bamboo and the documentation would shrink but we need approval from the community.

7. OpenMRS 2.0 should not be used for Platform 2.0 as it creates an issue with Reference application 2.0:

@wyclif pointed out that OpenMRS 2.0 has already been used for OpenMRS Reference Application 2.0 in JIRA , Having the same name for Platform will be confusing. Maybe having Platform 2.0 would make more sense.

8. Two Different Release Process Pages Under the Main Release Process Page:

The present release process page is completely about platform release process and the Reference Application Release process is a link under it, it would be nice to have a generic main page and links to the two different release processes.

Thoughts?

k.joseph · November 13, 2015, 8:30am

I hope the code freeze in mid January is not on both openmrs core/release branch and to be included modules!

I appreciate making the release process more automated, however as a starting release manager i more so appreciate it if am mentored through the manual release processes such that when i meet with organisations that are not automating it, i have no drawbacks to do it myself.

Thanks @maurya for this good post

terry · November 13, 2015, 7:24pm

thanks for the work on this. i have a few comments.

i like having a stated release timeline that is ‘generic’ to some extent–and has specific timelines stated. I don’t know enough about our development/ testing to comment on whether these are reasonable, but it seems like they are. As far as the selection of the release manager–the sooner that person is involved, the better. Perhaps we could encourage the current release manager to identify the next one, and have them work together ? that way, the next release would go better. Also, we should somehow have the release issues track ( i assume that we already do that) to try to identify/ avoid them in the next release
sounds great
I woud involve Jan in this discussioN ( and i am also willing to be involved). The implementers and users should be doing the prioritization. i think that this is part of Jans work in the strategic objective # 4- but we should make sure that she is involved now. I dont know if voting is the best way to approach this. we should have some criteria that is used beyond voting ( one criteria could be, for instance, impact on health outcome or something like that). @jan can help with this one
communication; i agree with your proposal here. if issues aren’t addressed, we need a mechanism to track and send out why. I dont know JIRA well enough; does that have this functionality?
awesome and we talked about this at the camp; would be great if we could do this for some longitiudinal/ historical presentation prior to the camp. for instance, can we track the statistics in 6 month increments ( starting X up till December 2015) and present them? we need this for the annual report also. i think that we need to highlight the stats some other way also; perhaps as a link on the atlas?
how would / will we ask for the community approval? can we do that at at the summit?
this seems to be a naming issue, right? it makes sense to have a naming convention that people will understand. I like the idea of reference application and platform versions ( as opposed to OpenMRS x version–that does seem like it would be confusing; does the community need to approve this and/ or can we just put put naming convention guidelines? 8 definitely; awesome idea. we should do that prior to the summit

thanks for the time/ reflection/ input into these ideas. amazing. terry

maurya · November 14, 2015, 4:35am

Great! Thanks for the replies @k_joseph and @terry

@k_joseph yes it is only for the modules, there should be some other timeline for the platform. And though it is good to learn the whole process, It might soon become automated everywhere

@terry, Thanks a lot for taking the time to post a reply for each of the point mentioned. To clear a few questions you asked:

The release issues are unofficially tracked by the release manager and they update the wiki as required.
Great! I Completely agree and @janflowers and others in others Objective #4 can come up with a better solution no doubt. I will request this to be added in the activities/tasks.
I am not aware of any such mechanism in JIRA, this can be done manually for now.
We can get the data incrementally for every 6 months manually. For the report, I can get the data. Will post it in Talk.
I think this mostly concerns the developers and can be handled in a developers call. Presenting and receiving feedback in the summit should also be great.
Even this needs to be discussed in a call and put in the guidelines.
I can create/reorder these pages accordingly before the summit.

terry · November 24, 2015, 3:13pm

thanks Maurya. Jan has been working on this so i think that she will love to help. if we are going to do number 3 manually, should we set up some spreadsheet mechanism to track and review. if you can get the data for 4, that would be great. i would like to include that in the annual report. can you also present that data/ have that data for the summit? we should figure out something more than just downloads ( for instance, impact) but i am not clear how to do that yet. 6. should we do a session at the summit , asking for input? 7. would be great to reorder prior to the summit. Can we make sure that Burke et al are ok with the proposed naming conventions ?

thanks. terry

maurya · November 24, 2015, 10:35pm

Thats great!. To get something started soon a spreadsheet should work.

Apologies for the delay. Here is the data. I think this should be find for the report. If you need some more detail let me know. the format for the following data is Time Frame - Number of Downloads - Number of Countries/Territories Downloading it (The whole text is linked to the detailed statistics from sourceforge)

Just to make the data a little more easier to understand I made a couple graphs in excel

But, I am not quite sure the above one quite captures the impact. Maybe we could use the image from Sourceforge itself to better depict them:

The only impact metrics we can show by summit would be atlas results and Judy’s statistics from the survey. There are discussions going on in Objective 1 about how we can improve capturing the impact, but nothing concrete is yet decided.

I think @wyclif, @darius, @burke or any dev/5 should look into heading this conversation as I am not sure what are the exact upgrades that can be done. I can coordinate and propose one in the ideas page to get something started.

I can go ahead and do the reorder right away. But I would be more confident if it is discussed and agreed upon. There is a call for objective 1 tomorrow, where I can bring this up and see what they think about it.

terry · November 25, 2015, 9:56pm

perfect. thanks for doing that i would suggest that we put the download information into the annual report for CY 15 also. NICE!

maurya · November 26, 2015, 5:42am

Asked in the platform call today. Updated the Release Process Page with the reordering