Thanks Rowen... do the creator(s) of the script have time to take this on? We definitely should also update the script to put the hibernate mapping layer into the api project... I was only skimming the thread on this issue, so could someone who has a good sense of what needs to be done here enter a ticket for that as well?
Thanks, Mark From: [email protected] [mailto:[email protected]] On Behalf Of Rowan Seymour Sent: Friday, November 11, 2011 7:33 AM To: [email protected] Subject: Re: [OPENMRS-DEV] FW: HTML form entry changes https://tickets.openmrs.org/browse/TRUNK-2856 Wasn't sure what project to put in under - the original ticket to create the scripts was under TRUNK so I put it there. I've listed the issues I found when I did the htmlformentry conversion. Don't know if anyone else has had the same issues. We also discussed previously moving the hibernate mapping layer into the api project... so maybe that is something this script could do though I don't think it's as simple as putting moduleApplicationContext.xml and all the *.hbm.xml files in the api project because developers may be defining all their controllers etc in moduleApplicationContext.xml On 11 November 2011 13:48, Mark Goodrich <[email protected]<mailto:[email protected]>> wrote: Rowen, That would be great if you could enter a ticket re: fixes to mavenization scripts. I was planning on opening a ticket regarding fixing the omod/api layout, but I wasn't sure if that had been fixed already. Were there certain steps you took to change the project layout after running the scripts? I tried quickly a few weeks back, but I remember it wasn't as simple as just changing the project names. Mark ________________________________________ From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] On Behalf Of Rowan Seymour [[email protected]<mailto:[email protected]>] Sent: Friday, November 11, 2011 3:05 AM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] FW: HTML form entry changes Before Git fans start migrating all their modules... it'd be great to get some more information onto https://wiki.openmrs.org/display/docs/Migrating+to+Git so that we can all be consistent. Also it'd would be good that people doing migrations have access to a single authors.txt account mapping file which we can all add to, though obviously this contains people's email addresses so we don't want to make that too public. It also seems like mavenization would be sensible first step before git-ization, so it would be great if someone could fix the mavenization scripts so they work with the agreed omod/api project layout, and a few other problems I've noticed. Shall I open a ticket for this? @Kishore can you add some info to https://wiki.openmrs.org/display/docs/Migrating+to+Git about which scripts you used for the conversion of htmlformentry? On 11 November 2011 00:16, Darius Jazayeri <[email protected]<mailto:djazayeri%[email protected]><mailto:djazayeri%[email protected]<mailto:djazayeri%[email protected]>>> wrote: I was originally skeptical of Burke's "just give everyone access, and deal with issues if they become a problem" viewpoint. But it's grown on me. I think it'd be fair and good if the default JIRA setup for projects that we host on OpenMRS JIRA is that all OpenMRS committers can assess tickets. The module owner gets an email about this anyway. And I think it's fine to let a module owner opt-out of this if they're going to be more proactive, and want more control. -Darius On Thu, Nov 10, 2011 at 12:41 PM, Michael Seaton <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote: Hi Michael, Thanks, I understand your position. What I'm saying is that I _did_ observe a bug before and I _was_ able to fix it, but the owner of the module was out of contact for a period of time and without asking Darius to add me as an approver, I was unable to move that ticket forward. I'm not saying that there aren't points pro and con here. But I would like to get the community's input on this, and if the consensus is to let the community police itself and not add process restrictions unnecessarily, then I would hope that we're open to changing the way things operate. Regards, Mike On 11/10/2011 03:25 PM, Michael Downey wrote: Hi Mike, On Thursday, November 10, 2011 at 3:01 PM, Michael Seaton wrote: 1. I could check out the module code, reproduce the error, commit a fix back to trunk of the module 2. I could create a ticket to report this particular issue 3. I could _not_ mark this ticket as "Ready For Work", "Claim Issue", or "Assign Issue". That seems restricted. 4. Because of 3, I could also not perform "Committed Code" on the issue That sounds more likely -- I think a fundamental assumption is that the critical path for issue management is that bugs are generally observed (and reported) before they are fixed. It's good for communication and it's good change management. For OpenMRS core, I personally would be concerned with allowing everyone to do issue triage due to potential quality and release planning issues. Of course, there is inherent delay in such a model as it scales - see Mozilla's challenges with triage [0] for example. On the other hand, a module developer or may choose otherwise (which is fine, of course) and can add multiple individuals or indeed all JIRA users into the "Approver" role which can triage issues. Fortunately, JIRA like GitHub has decentralized administration which allows this flexibility and independence, which I agree is important for a large distributed project like OpenMRS. Regarding the example at hand, I notice you are listed as in the Approver role for this project - I assume that's a recent addition and you'd be able to triage tickets for this project in the future. Michael [0] http://tylerdowner.wordpress.com/2011/08/27/some-clarification-and-musings/ ________________________________ Click here to unsubscribe<mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected]<mailto:[email protected]> with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l] -- Rowan Seymour tel: +250 783835665 http://twitter.com/rowanseymour ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
