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]> 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] [[email protected]] On Behalf Of Rowan Seymour [ > [email protected]] > Sent: Friday, November 11, 2011 3:05 AM > To: [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]>> 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]>> 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]?body=SIGNOFF%20openmrs-devel-l> > from OpenMRS Developers' mailing list > ________________________________ > Click here to > unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> > from OpenMRS Developers' mailing list > > ________________________________ > Click here to > unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> > from OpenMRS Developers' mailing list > > > > ________________________________ > 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] > -- *Rowan Seymour* tel: +250 783835665 http://twitter.com/rowanseymour _________________________________________ 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]
