blankev wrote on Thursday, July 16, 2009:
Would it be an option to keep an almost stable sub-version of OpenEMR to download with little risk for an OpenEMR version with all recent options and reasonable stable version because many of the new features are showing of and could attract more user with even more bright ideas for future of OpenEMR
tmccormi wrote on Thursday, July 16, 2009:
That is something I think we need very badly and I have been actively promoting that. Patches that are well tested against 3.0.1 and agreed to be generally useful and any new forms that are contributed.
MI2 would be happy to own the integration process for that branch.
–Tony
bradymiller wrote on Friday, July 17, 2009:
My initial reaction is that it seems like a waste of openemr’s currently limited resources; difficult enough getting a release out there every 6 months deployed on windows/ubuntu/appliance etc. Seems like that during a normal openemr development cycle, releasing each patch in tracker could be done (the time to do this though adds up), but this development cycle has seen lots of changes upon changes in the cvs code as illustrated by merging Tony’s most recent patch based on 3.0.1. Wondering how you’d deal with sql database updates. Also wondering how difficult this will become when the onslaught of update for CCHIT functionalities start coming in. Tony, how would the process work? Any other open source projects doing this to illustrate it better for us.
-brady
tmccormi wrote on Friday, July 17, 2009:
All of my experience is in managing this in a corporation with 7-10 product lines (multi-million lines of code each) at various stages of release and enhancement and 200+ developers scattered around the world. This does not seem hard to me at all… but in the corporate world we could dictate how the bugs and enhancements would be identified, prioritized and deployed as well as how and when the branches would be merged and by whom.
As to Opensource … the big guys, Ubuntu, Mozilla, et al continue to patch and support exiting stable releases while working on the next big thing. In fact they have "auto update" that lets you know when something has a critical security patch or bug fix. AND they support custom add-ons in the form of plugins that the end user can easily install without touching the source code. This is true of PHP based tools like WordPress as well.
OpenEMR has good support for add-on Forms, we could easily extend that to Reports. The new List management and Layout tools provide a really good basis for end user customization. Other parts of the system are harder and could be modularized to support options and custom code addons. More thoughts on that later in a different thread.
–Tony
All that to say that I think it’s very doable and, considering our target “market”, I think it’s a requirement to compete in this field.
bradymiller wrote on Friday, July 17, 2009:
hey,
Regarding trunk and merging, sounds great, but we’re the small guys here (how about some opensource examples where the number of developers can be counted on one hand)… My coding/development experience is really just limited to OpenEMR, so Rod’s thoughts here would be much more useful than mine.
Regarding modules, agree that those proposals would also be nice. Put these patches in the tracker and I’d gladly commit it 
-brady
drbowen wrote on Friday, July 17, 2009:
I would be in favor of a release at this time. This si primarily due to the recent addition of several important improvements that I would like to see disseminated.
1) The multi-language is complete.
2) Bill Himmelstoss has the muti-facility code committed on SourceForge. I know the MMF Systems in New York want to start developing code and are waiting on Bill’s muti-facility patch.
3) Tony McCormick I believe has made some enhancements to the practice management.
I think it is easier for practitices to upgrade and get used to the changes if these are done in smaller chunks. A releasse schedule of 4 times a year may more sense given the rapidity of the recent advances.
In fact, the multi-language code by itself should probably earn this the title of 3.1.0 or 3.1.0-rc1.
We will need to decide which languages to include. There should be some minimum translation level as a percentage to be included in a relase.
The number of developers on our recent telephone conference call was closer to 25 individuals. James Perry, Jr. Tekkno Genius has been promising to help with the releases.
Sam Bowen, MD
blankev wrote on Friday, July 17, 2009:
Sam, I fully agree but I see you forgot to include:
4. Growth Charts for male and female from 0 to 6 and 6 to 20 years. These are very nice to have as a demonstration available! May be the inclusion of other anatomical relevant pictures in due time in the near future, can be another good reason for an intermediate sub-upgrade.
Don’t wait for the Growth charts to have “ASAP”, as possiblity some metric solution for the internationalization project… ;-(
5. On medication prescription printing a lot of improvement has been made and is also a great new asset for OpenEMR.
6. And all other things that are gowing and growing behind the visible scenes.
And all programmers who did such a tremendous job should have some place in this whole OpenEMR version. Could be mentioned and included in SQL-upgrade as Programmers in the Address book?
" We are in urgent need of a heroes corner! "
Pimm
bradymiller wrote on Friday, July 17, 2009:
hey,
There’s still multi-language work, UTF-8 testing, and a major bug fix; probably about a month. I agree it would be nice to get a release out before all the cchit stuff starts rolling in, since this will definitely prolong the next release.
Rod, is there a way to branch the code to prepare for a 3.1.0 release (we’d only commit multi-language stuff and bug fixes here), while then commiting all update in the cvs branch??
Proposed things that still need to be done:
Major bug fix (missing an entire mysql table):
https://sourceforge.net/tracker/?func=detail&aid=2796659&group_id=60081&atid=493001
https://sourceforge.net/forum/forum.php?thread_id=3281726&forum_id=202506
Multi-language:
1. Internationalize vitals form (Jason possibly working on)
2. Internationalize several more forms
3. Simplify the buggy dutch forms or move them back to contrib
4. Polish internationalization in calendar
5. Internationalize several more page in openemr (letter generator and chart finder)
6. Import a new pdf library, TCPDF, to allow UTF-8 characters in pdf’s. This is the largest project, and will require re-coding pdf generation for letter generator, precriptions, immunization records, growth chart, and possibly even billing (since may have spanish characters in US bills). As of now, no special characters (including spanish) work in any of the generated pdf’s.
7. Testing UTF-8 characters to ensure no corruption of them during openemr use. Several of the Greek users I am hoping will do this.
Translation tables:
I’d suggest just keeping all languages in the sql tables (except of course dummy and dummyUTF8). I’ve put a nice set of options in globals.php to control if menu is displayed and what languages are displayed; we can optimize this for the default installation. Check out the language translation section in globals.php.
-brady
sunsetsystems wrote on Friday, July 17, 2009:
Sure, I’ll create a 3.1.0 branch shortly.
bradymiller wrote on Friday, July 17, 2009:
cool,
Also found a nice way to commit future updates to both the branch and head here (for updates that need go to both 3.0.1 branch and main branch):
http://webwork.maa.org/wiki/CVS_Branching
So will use above for bug fixes, multi-language updates, or other stable updates. And will put newer stuff (like cchit stuff) that isn’t stable only in the main branch. So Jason’s possible work on internationalizing vitals form (metric and standard in one) would go to both branches via above link.
Does that make sense Rod and Jason?
-brady
sunsetsystems wrote on Friday, July 17, 2009:
OK, this is done. The branch name is "rel-310". What you want to do is check out this branch into its own working directory. Taking clues from https://sourceforge.net/scm/?type=cvs&group_id=60081 you can do it like this:
mv openemr openemr-head (if your main repository already exists as "openemr")
export CVS_RSH=ssh
cvs -z3 -d:ext:developername@openemr.cvs.sourceforge.net:/cvsroot/openemr co -P -r rel-310 openemr
mv openemr openemr-310
… where "developername" is your Sourceforge name.
The CVS manual is at:
and you can read about branching here:
Note that any fixes you apply into openemr-310 must also be applied separately into openemr-head!
tmccormi wrote on Monday, July 20, 2009:
Brady,
I’ve been out all weekend, lot of good chat on this topic.
The branching model you referenced should be quite adequate. It’s one of the “standard” methods and general works well if the “code freezes” are adhered to.
–Tony
bradymiller wrote on Tuesday, July 21, 2009:
Rod and Tony,
Maybe I was a bit premature on the branch. Although it’s been a great learning experience, I’ve become aware that I’ll potentially be spending most of my “openemr time” ensuring code committed from head goes to the branch, and not on actually finishing up the above internationalization stuff. For example, Rod committed some nice stuff to head today, and I’
d like to migrate it to branch also, but this is busywork that eats up time.
We’re still probably about a month from even getting to the code freezing stage of 3.1.0 release. The real reason I think the branch will be useful is to avoid the hopefully massive amount of CCHIT code commits (I am assuming all these will take the internationalization backwards temporarily) from prolonging a stable release. But, at this point we’re still waiting on that to happen; so perhaps the branch is just causing needless busy work right now (the only wanted difference between the branch and head right now is the version in globals).
Options are:
1. Continue committing everything to head and branch, and have the each developer responsible for their own code. When we start getting commits from other developers (especially cchit stuff), then can begin to only commit these things to head unless of course it’s stable enough and useful for the branch.
2. As number 1 but assign a developer to ensure things are going right (for example would commit Rod’s stuff if deemed it should go there). Tony sounds like he has experience in this role.
3. Ditch the branch for now and wait for the awaited onslaught of cchit commits to come in before making the branch. At this point could then decide on option 1 or 2 above.
-brady
sunsetsystems wrote on Tuesday, July 21, 2009:
Brady, I thought the idea with this branch was to get a release out based on current code. As such I have been committing new features only to the head, and only bug fixes to the 310 branch. I figured others would be doing the same.
Option 4: Is it not reasonable to test the 310 branch and then proceed with a release?
drbowen wrote on Tuesday, July 21, 2009:
I agree with Rod. The intent of the relase 3.1.0 is to get the bug fixes out and to let those running multi-facility installations to start using Bill Himmmelstoss’ patch.
1) The multi-language as is, is dramatically better than what is in 3.0.1
allows the release of the Bahasa Indonesia 86%, Dutch 100%, Greek: 85%,
Spanish 100%, languages. I think a language should be at a minimum 80%
translated to be released.
2) Bill Himmelstoss has the muti-facility code committed on SourceForge. I know the MMF Systems in New York want to start developing code and are waiting on Bill’s muti-facility patch.
3) Tony McCormick I believe has made some enhancements to the practice management.
4) Growth Charts for male and female from 0 to 6 and 6 to 20 years.
5. Medication prescription printing - improvements
I think you are trying to cram to much into what is really intended to be a bug-fix release.
Sam Bowen, MD
bradymiller wrote on Tuesday, July 21, 2009:
Dam, Rod, and other developers,
SOAPBOX:
“bug fix release”… are you kidding? The main tenets of this release are UTF8 and multi-language (the others are mere patches, ie MMF could simply apply Bill’s patch to their code, so no reason to push a release for just this). Currently, anything with PDF’s can not be internationalized meaning prescriptions, growth charts, shot records; this can be dealt with by using css html prints like the recent ‘letter generator’ changes. Let me say that I think it would be very lame to release with these “bugs” in a “bug-fix release”. There is also about 300 more constants that need to be added to the translation spreadsheet and then translated by the major languages(dutch, spanish, greek). We also currently have no simple testing mechanism for our 3.1.0 branch. That being said, we can focus on the things required for internationalization to work and reduce the stuff I listed above.
OVERALL PROPOSAL(with timeline):
1. Create mechanisms for testing the 3.1.0 branch by hacking another cvs demo appliance together also creating nightly builds (this weekend-7/25) (me)
2. Integrate the last list of english constants (about 300 more) into the translation spreadsheet (next weekend-8/1) (me) - This gives 10 more days to finish up code changes which include chart finder and css html alternatives to pdf’s
3. Give translators time (two weeks) to translate new constants and test all their current constants(8/15).
4. So probably ready for release weekend of 8/15
Does this timeline sound good? I guess with Rod’s recent nifty changes to developemtn tip cvs, I figured since nobody’s even testing the branch yet, why not include it?
-brady
bradymiller wrote on Tuesday, July 21, 2009:
error above:
Dam is supposed to be Sam (sorry)
-brady
tmccormi wrote on Tuesday, July 21, 2009:
I’m with Rod and Sam here. My point for a 3.0.2 release was bug fixes and minor enhancements to things that are “not good” in 3.0.1. All back porting from the tip does is double the work (as you found). The point was to apply ONLY the changes that we deemed critical bug fixes (not related to internationalization) and low risk enhancements. Those should ALL be put into tracker and then integrated 3.0.1 branch. Some method for agreeing / approving the integration is needed.
Internationalization is a MAJOR release 3.1.0 and should be carefully handled and not rushed. I do not recommend putting any of that work in a patch release.
–Tony
bradymiller wrote on Tuesday, July 21, 2009:
Tony,
I disagree with the POINT. Read this thread fully; the branch was actually created for 3.1.0 release (called rel-310) from my message:
https://sourceforge.net/forum/message.php?msg_id=7509634
Your just pushing your previously discussed agenda of getting a bug release branch of 3.0.1 (which I agree would be nice). If that’s what you want to do, then wouldn’t you need to apply patches to a branch before any of the internationalization/utf-8 stuff (there’s been a large amount of under the hood utf-8, internationaliozation, lists, layouts, stuff that has happened since the 3.0.1 release); otherwise this would not be a simple bug fix release and as I discussed above you would be releasing a bug fix release with other known unrelated bugs???
Am I missing something here?
-brady