Requesting /dev/4 stage for Bahmni team members

[burke (Burke Mamlin)]

@wyclif

Interesting post Darius, thanks for sharing it, in Karl’s post one of his arguments and assumptions is that the team regularly looks at and reviews all commits in the project which personally i rarely do, not sure about the other devs, instead we review pull request before they get merged but i do agree with the honor system.

The main point is that a web of trust can often meet need and be more beneficial than a mountain of painful, granular authorization restrictions trying to mitigate the risk of someone doing something wrong in a system specifically designed to track changes and easily revert them.

As far as code review goes, giving anyone push access to core, including temporary access, should not substitute for our convention of code review for all commits to core:

All commits to core should have two eyes on them

A /dev/5 (much less a /dev/3) pushing non-trivial changes to core without someone else seeing them first or merging their own pull request would not be following this convention.

[bharatak (Bharat Akkinepalli)]

Hi All, After the MVP version of OrderSets being merged, we think its time for a rigorous testing. I am thinking we are ready to do a beta release and I am stepping up to be the Release Manager for the OpenMRS Platform 1.12 But I am a /dev/3, so, as discussed on the thread, what are the next steps.

[wyclif (Wyclif Luyima)]

@bharatak i believe a /dev/3 can be a release manager, as for the release process, you can follow our release process wiki page, are you skipping the alpha and going straight to beta?

[wyclif (Wyclif Luyima)]

And thanks @bharatak for volunteering to be the release manager

[darius (Darius Jazayeri)]

@bharatak

I am stepping up to be the Release Manager for the OpenMRS Platform 1.12 But I am a /dev/3, so, as discussed on the thread, what are the next steps.

@burke, Bharat needs write access to openmrs-core to be able to tag 1.12-beta (or alpha, per Wyclif’s comment).

Can we go ahead with your “temporary-core” github group plan? What needs to happen to do this?

[burke (Burke Mamlin)]

I’ve added @bharatak to the temporary-core team. Please reply here when the access is no longer needed.

[bharatak (Bharat Akkinepalli)]

Thanks @burke for the access. I agree with @wyclif that we can go with alpha release. I will carry on the rest of the process tomorrow IST. Will ping back on this thread about the status.

[bharatak (Bharat Akkinepalli)]

Looks like I need the access to maven repo for uploading the artifacts by running the following command “mvn clean deploy --batch-mode” This is available in step 10 of Alpha Release process. Can you please let me know how to get the access for maven repo?

Also, I do not have access to Bamboo. The release process documents two approaches one is manually, other one using Bamboo.

[darius (Darius Jazayeri)]

@bharatak, you will need to to ask helpdesk for access to CI and to maven.

(@helpdesk, please action this and Vinay’s request)

@maurya, @wyclif, do we really say that it’s okay to release manually or via bamboo? Shouldn’t we have just one process?

[r0bby (Robert O'Connor)]

I have added both @bharatak and @vinay to bamboo – it is imperative th at they change their passwords IMMEDIATELY.

In addition, I added an account for @bharatak to the wordpress. Immediate password change only has to happen on Bamboo.

[bharatak (Bharat Akkinepalli)]

Thanks @r0bby and @darius I have updated my passwords.

[wyclif (Wyclif Luyima)]

I don’t think you can release core from bamboo because that hasn’t yet been set up from what i know.

And just to contradict myself, you might want to think of 1.12 as a maintenance release and historically we don’t do alpha, beta, RC release for these, it may be fine to go straight to beta.

[bharatak (Bharat Akkinepalli)]

I have released the beta version of openmrs 1.12.x using bamboo today. While following the instructions, I have hit a blocker with building the openmrs-standalone. The README asks us to download the demo sql file per release from this location. The Demo data is unavailable for 1.12.x release. I would like to understand the process of generating it. Thank you.

[dkayiwa (Daniel Kayiwa)]

I have done some edits in the readme to address your question. Is it clear enough for you to proceed?

[bharatak (Bharat Akkinepalli)]

@dkayiwa Thank you. The instructions are fine now.

[darius (Darius Jazayeri)]

@burke

We noticed today that no Bahmni tech leads are approvers for JIRA tickets in openmrs-core or the legacyui module. (At least @angshuonline is not.)

For example today TRUNK-4885 was created (by a Bahmni dev) “just-in-time” to send a Pull Request for the Concept Attributes work. But as a newly-created ticket, it was just in “Needs Assessment”.

How do we want this to work? Since the Bahmni team is empowered to work on the Concept Attributes feature, should someone from that team be empowered as an Approver and/or Administrator in the TRUNK project in JIRA? If not, is the model that “someone” will notice this at some point and mark the ticket as ready-for-work?

I peeked at the JIRA configuration and I don’t really understand how I would denote someone as having elevated JIRA privileges, and our current list of people on the TRUNK project is extremely outdated.

[pascal (Pascal Brandt)]

@darius

is the model that “someone” will notice this at some point and mark the ticket as ready-for-work?

I’m not sure how it should work, but I definitely don’t think this is a good model ︎. At the very least the dev working on the ticket should ping “someone” to take a look.

Question for infra team: How fine grained are JIRA permissions? Can people have access to assess tickets that are part of a particular epic or milestone?

[burke (Burke Mamlin)]

@darius

How do we want this to work? Since the Bahmni team is empowered to work on the Concept Attributes feature, should someone from that team be empowered as an Approver and/or Administrator in the TRUNK project in JIRA? If not, is the model that “someone” will notice this at some point and mark the ticket as ready-for-work?

I don’t think we’ve addressed JIRA privs since adopting dev stages. It would seem logical to me that, like GitHub permissions, our permissions in JIRA should be liberal and all /dev/3+ should be able to administer workflows across projects. I’ll start another topic to discuss with infra team about if we are (or could) drive JIRA group memberships (and thereby permissions) automagically from dev stage assignments. Then we’d only have to manually manage exceptional cases.

@darius

For example today TRUNK-4885 was created (by a Bahmni dev) “just-in-time” to send a Pull Request for the Concept Attributes work. But as a newly-created ticket, it was just in “Needs Assessment”.

IMHO, any /dev/3+ at Bahmni should be empowered to perform the assessment to get the ticket into a “Ready for Work” status.

@pascal

Question for infra team: How fine grained are JIRA permissions? Can people have access to assess tickets that are part of a particular epic or milestone?

From what I’ve seen in JIRA, permissions are granted by roles which can be either global or project-specific. I don’t think there’s anything to dynamically change permissions based on issue assignment (there may be a plugin). In any case, I’d rather manage permissions socially rather than technically (i.e., have a liberal permission policy that gives permissions to as many people as possible and use conventions/education to manage expectations).