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.
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.
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.
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.
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.
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.
IMHO, any /dev/3+ at Bahmni should be empowered to perform the assessment to get the ticket into a “Ready for Work” status.
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).