Added some basic scripts and guidelines to migrate the repo form svn to git at https://wiki.openmrs.org/display/docs/Migrating+to+Git
On Fri, Nov 11, 2011 at 1:35 PM, Rowan Seymour <[email protected]>wrote: > 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 >> > > > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > -- Regards, Kishore Kumar Yekkanti. _________________________________________ 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]
