2007-03-22 Developers Conference Call
- Former user (Deleted)
<html><head><title></title></head><body>h1. Date
22 March 2007
In Attendance
Paul Biondich
Ben Wolfe
Burke Mamlin
Chris Seebregts
Hammish Fraser
Maros Cunderlik
Justin Miranda
Darius Jazayeri
Shaun Grannis
Minutes
Different ways people can potentially submit code:
Burke- The primary way that most larger open source groups do this is for the casual, kind of someone coming along, is to make your changes to code, create a diff and submit that as a patch to the code base. That goes to a reviewer and they, based on their review, commit it to the code. Another, and not necessarily mutually exclusive, tool would be to create kind of a playground, creating a space in our repository for people to join up and be able to commit code in that space. It would get tested and then moved over to our main repository and then, I think, there are pros and cons to both and I think getting down to the details of how you talk people through that. Patches is probably the easiest, in terms of teaching people how to do that. I was looking through a number of different projects and one is like droopal, if you go through their documentation, they have some nice documentation of how to get diff up and working and kind of step you through that process. We can mirror that kind of stuff. The question is going to be that we are going to have to create some kind of reviewing process. I’m in the mind set that nobody gets commit rights to the code into the trunk or to our alpha until they have earned that.
The question was asked â€ÂÂSo, step one is writing a module?†Burke-Yes, I think we would encourage people to write a module. We could also allow them to create branches, in a playground, in the repository. Paul-Why would the branches need to be in a playground?
Why couldn’t they just be a branch alph alpha? One of the notions that Dan talked about quite a bit is that there is a power to giving people an opportunity to use our repository. It makes them feel like they are part of the initiative. If you say that some of the people go to the playground and some people can play in the main code base, you’re creating hierarchy's where they don’t need to exist.
Burke- I’m not sure I want a world where anybody can come in and create a new folder. It could still be in our repository, and maybe we play by the same rules. If we are playing with an idea, we do it in the playground until it gets bumped up. Alpha is a little different than a playground. Paul-assuming that they are dumb and aren’t worthy of contributing to our branches or code base is sending a message that could be a bad one. Maros-Having the rule that the first thing, before we know anything about you, you don’t commit directly to the main repository. Paul-Don’t people have to have privileges in order to even use the repository? I would assume we are not creating user accounts for just anyone. Isn’t there a round of screening that goes through that?
I would argue, and this is just my opinion, that we should try to flatten the hierarchy as much as possible. We should make people feel, when they come to this, is that they are being treated as a peer and not as a tester. Burke-I agree with that but I also want to make sure that we don’t end up with surprises in our trunk. Paul-That’s impossible. If you’re giving people the ability to do anything in the trunk then that is deadly. Trunk is something that no one should be able to commit to, unless we all sign off on what’s in the alpha and then you merge alpha in to trunk. Maros-That’s pretty reasonable. Burke-So, at the top, you have our trunk, you have tags, which are releases and I assume both of those would be protected, and then you have modules and we have been fairly loose with if someone’s creating a module and they want to keep their source on OpenMRS, we create a folder, essentially under the module folder for their module and then they have rights access to that. That has worked fine. Paul-If we have given them an account to the repository then they should have the ability to make a module. We should give them that ability. If they decide that they want to make a module then that is what the repository is for.
Burke-I would like to give access to the repository. The idea of a playground would be to say, â€ÂÂYou can get your code up and commit it to OpenMRS into the repository on day 1. We don’t know who you are. Come in join our playground and get your code up there and then share it, let us know you’ve added it to the playground and ask us what we think.†I would love for those things to be able to blossom and show up, without this sort of â€ÂÂyou have to meet us and we need to get to know you and we can approve youâ€ÂÂ. That’s the idea of the playground. If they have something and we like the way it looks then it can come out of the playground. I would rather elevate people, once they have proven themselves. You don’t want a project where anybody or somebody can just come in and totally screw up your repository. Paul asked what the group thinks. It was said that anyone who seems legit, at first glance, we can give them an ability to playground and once we’ve seen them do something that is good then we can bump them up to the ability to commit to the real stuff. Paul-If you are giving someone an account on the repository haven’t you already screened them? Ben-We would create a module folder under their name in the module folder and they have full access to that. However, if we give them one level up then they can touch the form entry modules, the reporting modules. We can make a branch off the module. Burke-We don’t want them writing to trunk, we don’t want them writing to tag because those are our releases. So, it comes down to two other folders, which are branches and modules. I don’t want to have a module that has 100 names in it. I would prefer to have a module directory that when you go to it has a list of active modules that people are working on and personally, I don’t see any kind of elite club. If you want to create a module and you want it to be an OpenMRS module, hosted on OpenMRS, you just email this person and say, â€ÂÂI need this folder created†and then it’s just created. It gives us exactly what you’re looking for where anybody could add a folder.
Paul-No one can write to alpha or trunk. That could include us. We have to start rationing down what we do, as well. If we are going to enforce this on new developers then we need to enforce it on ourselves. I think people created branches in modules is excellent, as well. That is exactly how you would want people to extend a module. Burke-If they want their module or what they are working on to go in the module directory then they email us and say, â€ÂÂWe want to add this module†and then we create a folder for them and give them access. We can control who has right access to that folder and then if they want to play and create a branch off of a module then they can just go off into branches and make something there. The question is, do you create a playground under branches that is open to everybody or do you just have branches open to everybody? I think what I am looking for is by having a folder, under which we give right access to anybody who has an account, opens it up to everybody. Particularly we can say that with alpha we can subtract all the right access and add it just for particular people. With the access, we can say, if this parent folder, say branches has right access for anybody with an account, we can say this particular alpha sub folder we will remove that right access and we’ll only add it back for select people.
Paul-Just for what it’s worth, we need to decide what behavior we want and just know that this guy that I talked to a google is one of the lead developers of subversion, so I can just ask. Burke-I think we have come down to, trunk and tags are protected and modules to the point of you have to talk to us to make a folder for you. That’s open to anybody who can make a good argument for why they want to add a module. Then, under branches, I believe we can make it so that, if we wanted, anybody can go in and make a branch and then we can turn off alpha so that one particular branch would be kind of specially treated. Paul-The subversion project has three or four people that can commit to alpha and one person that can commit to trunk and everyone else commits branches, regardless of how senior they have been in the project. Burke-The one question would be remaining would be is if you go in and create a Paul branch, can I, because I have an account, go in and commit some code to your branch and right now, the answer would be â€ÂÂyesâ€ÂÂ. Paul-If you don’t like it the author can prune the branch.
Some discussion about diffs and patches. Burke-One thing would be to have people submit their patches through track. So, if you have a patch that addresses a particular problem or adds and enhancement you either go to the ticket for that or you create a ticket for that problem or enhancement and then submit your patch, as an attachment. It would be a text file attached to a ticket. We need a method where if I have created a patch that I would like to see applied to OpenMRS, I have to email it to somebody to review. The trick will be that we need to be able to recognize when patches were submitted. I think we could probably do that through the time line or we have some trigger that tells them to make a ticket and cc a particular person. Track will also be taking care of most of that because anybody that was involved on that particular ticket will get an email letting them know it’s been changed. The issue will be that we will need to have people, like our current coders, that would step up to the plate as patch reviewers and we could devote a little effort to get people up to speed on how to do that. Part of this process will be us creating documentation to walk people through how to do this. Paul-This all has to be completed and up online by the time folks start.
Paul-How do people feel about closing off alpha to submissions? All agreed that it has to happen. Paul continued with asking the question, â€ÂÂWhen can we go ahead and establish a date for when that is going to happen?†The response was to just lay out a plan for it and everyone will have to work around it. Paul suggested to do the switches to the sub-repository as soon as possible. After some brief discussion Burke asked, â€ÂÂWhat permits a person to commit to alpha?†The response was that Ben was the main contact for permission. Burke will be the backup when Ben is out. Darius-So, at the moment we have alpha deployed in Rwanda. You would envision that we each actually have a branch off of alpha called PIH Rwanda deployed there and if we need to instantly fix something we would go to that branch? Ben-If there is a couple of files that are edited, and it’s not something that is this huge task, I don’t want to be the one that every couple of hours I get an email that says, â€ÂÂcommit this to alpha.†I think we keep trunk up to date enough. It’s only about a month behind alpha and it’s a trusted thing. That’s what we run our production off of. If you need to really have bleeding edge, you could run Rwanda off of any code you want. Burke-In my mind alpha is kind of that staging of where we have changes and it has gotten to a point where we think they are production ready but we want to get them all into one code set that we can compile, run through unit tests, and kind of prove to ourselves that it is functional and everything passes the test before we move it over to the trunk.
After some discussion Burke said you could create a copy of alpha and then merge in your changes that you need right away in to that and compile off of that until changes can be done. Justin-Why would we actually need to get something in to alpha? Paul-Just compile a branch. Justin-It’s more like if someone submits a patch, is Ben the only one that can commit that to alpha, once he has agreed to it? Burke-What if we have ten branches out there of folks that have done stuff and now we want to bring alpha up to speed to kind of test everything out and send it over to the trunk? Does Ben have to go through all those merges on his own? Darius- If we write a whole bunch of functionality, I mean, if Ben wants to be the one that merges all of that into alpha and tests it then okay. However, any organization that writes a bunch of code, should be responsible for the work of merging it in. Ben-I think if the branch is up to date with the latest alpha, the merge from the branch to alpha is fairly trivial. Shaun-Is there a formal process to keep everyone up to date on what’s happening with branches? There is nothing to stop a branch developer from coding for two years and then coming back and saying, â€ÂÂOh by the way, I want all this stuff added in.†I think there needs to be some way of communicating at a fairly regular basis. You know, we’ve added a ton of code, a ton of features. Either it’s personal responsibility or it’s a formalized process. Paul- Does anyone want to take on the responsibility of merging branches back into alpha? Justin said he would but would need a crash course from Ben. Ben describes the post-commit review where they watch track and then go to someone’s code and look through it and we do not have a process for that right now. There has to be a way of saying, â€ÂÂThis code is not up to par. You need to change this, this and this.†Justin-Is there some way to tell someone their code sucks rather than just by email? Shaun talked about there being a pre-commit review because there has to be some accountability partners. Burke-my sense is we have developed as many questions as answers in the process and it would be good to take those to a few larger open source communities and say, â€ÂÂwe are struggling with these issues. How have you handled them.†and we may be able to find them through their documentation or get it from them directly. Ben’s reservation is having to do pre-commit reviews on everybody’s code. There has to be feedback from everyone. We have to be able to accept and give feedback. We also need to define what our expectations are.
New Logos Discussion:
Everyone looked at the new logo. Some discussion about changes. Various versions of the logo were viewed and discussed. A logo design needs to be decided by next week. Anyone who has ideas on the logos need to have their ideas on the page by the end of the weekend.
GUIDs:
Burke asked if GUIDs is the right way to go or is anyone saying that auto number is a preferred way. Darius said he assumed that having auto numbers for some things and GUIDs for things we needed to synchronize is the way to go. After some brief discussion Ben asks-How would we handle, if we had local IDs and GUIDs, how would we handle the synchronization when two concepts are created of the same local ID and different GUIDs but then if we are connecting forms to concepts on the local ID then those are screwed up and then those have to reference the GUIDs. So, what’s the point of the local ID? Burke-It’s local ID, so you would have a 5197 from AMRS and a 5197 from RG staging and those would be two different local IDs for two different sources. I think if you are controlling the dictionary in one place, as long as there is one location that is the only writing.....you know the only place that needs an HL7 source ID, which is your institution, is wherever you are writing to the dictionary. If you want to be able to write to both of those then they need two different source IDs, and I would picture that would be a global property, you would assign local IDs in the concept dictionary as well as the key would be a GUID. When you transfer those, you would have the GUID’s..let’s say you are bringing them to your staging server, where you have GUID and you would also have this is from HIV EMR concept 5192 and when you put that into your staging server you would look and if you saw that the GUID already exists, you would take whatever local ID that is on the staging server, if you say you haven’t seen this GUID before and you would store that concept but you would come up with a new local ID for your staging server. Someone said that they would agree with Burke but that probably within an enterprise you would want to have fewer concept name spaces then you have servers with OpenMRS installed on it. Paul disagrees adding that we have these two machines sitting right next to each other that are not connected and do not know each other and both people make a new concept for hemoglobin and have the same local ID but different GUIDS. So, when I merge those two together what happens? Burke-But if you are writing on two different systems because they don’t see each other then those need two different sources. Paul-That source needs to be stored in the concept table. They are both the same. How do you separate the two? Ben-When you are talking HL7 you send local ID and you send that storage source. Source is in our source table. Burke-Person left sends to person right and they send their concept for hemoglobin and it’s also 5192, just like person left, but the source is person left who is sending it. What I would do is when I got that hemoglobin from person left with a new GUID that I have never seen, I would look at the GUID and I would say that I don’t know this concept and so, I would create a new concept with that GUID. So, person right would get a new concept with that GUID and they would assign a new local ID for person right and they would store in the mapping table the fact that their new local ID 1234 is equivalent to person left’s 5192. Some discussions and then Burke-So, what I would so is when I got that hemoglobin from person left (local ID 5192) with a new GUID that I have never seen then I would look at the GUID and I would say that I don’t know this GUID and so I would create a new concept with that GUID and person right would get a new GUID and they would assign a new
GUIDS are definitely necessary to merge data but they are not the answer for all our IDs. They do not replace auto numbers. Any kind of data synchronization would have to go through a process of concept reconciliation. Paul-If I had two systems that were capturing form entry data and they were actually entering data into the system, how would you ensure that you maintain complete synchrony between those two tables and they look exactly the same, unless you had GUIDS? The mental exercise you should go through is to start backwards and think that the most atomic The only thing I can safely say today is that obs ID would be fine for it. Patient ID and concept ID is a problem, user ID and location ID’s are also problem. Burke-The GUID is basically the source and the local ID that makes a universally unique number. As long as AMRS is one server that anytime it’s making auto assigning numbers, is making sure it never makes collisions and every concept or location or anything that has an ID come out of that with AMRS appended to it. You then essential have a GUID as long as you ensure that you don’t create two AMRS’. Paul to Maros-If we provide you access to the HL7 manuals, and you find out what the character space is within an HL7 message, can you tell us whether a GUID would fit into the spaces for IDs? Maros said he could. More discussion will continue on this subject at a later date.
Meeting Adjourned
Agenda
Discuss possible switch to GUIDs for most table keys
Pros:
Easier to synchronize databases
Easier to merge data from external or remote systems
Easier to manage concepts among multiple servers (e.g., create anywhere, distribute as needed)
Cons:
Significant code change (all <tt>int</tt>s would need to change to <tt>String</tt>s for keys)
Additional database cost from longer keys? Are GUIDs slower? Is this a myth?
GUIDs exceed the 20-character limit for IDs within HL7 messages, so we'd need to keep a <tt>local_id</tt> (or similar) attribute to send along with an <tt>hl7_source.hl7_source_id</tt> within HL7 message — e.g., for patient, encounter, and concept tables.
The GUID does not work well for human useage (e.g., when linking or uniquely referring to a patient or concept among developers or data managers). Therefore, we'd like the <tt>local_id</tt> ''(some simple integer) attribute for patients & concepts for simpler communication/linking.
Begin planning for handling code submissions from non-committers – i.e., patches
Need a process for accepting patches
Need that process documented on the wiki
Required watching: How Open Source Projects Survive Poisonous People
Person/Provider dashboard (if time allows)
Need a dashboard for non-patients
Has some traits/tabs in common with patient dashboard: Overview, Encounters, Forms
New logo discussions
PDF describing management and distribution of open source project code trees: Code distribution process
</body></html>
</body></html>