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]> 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]> 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<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[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]
