I've added some information on tools for using Git. I've been trying EGit and the Maven SCM connector for Git. The Maven SCM connector doesn't create a project that EGit recognizes and I haven't yet figured out how to make it managed by EGit afterwards. EGit let's you clone a repository based on it's URL and then afterwards you can easily import that as a Maven project.
I also tried NetBeans and IntelliJ IDEA. NetBeans has an easy to install plugin for Git and IntelliJ IDEA comes with built-in support for Git and GitHub. I think I still prefer the command line but EGit seems pretty good, and there's always the GitHub app for Mac OSX. On 15 November 2011 10:24, Rowan Seymour <[email protected]> wrote: > Thanks Kishore > > Is there any way we can securely manage a shared authors.txt file for > mapping SVN accounts to Github accounts? Running a script on the SVN repo > can get a list of usernames but that doesn't tell someone what email > addresses are being used on Github. > > Do we envisage people migrating their own modules or someone doing this on > their behalf? > > > On 14 November 2011 21:34, Yekkanti Kishore Kumar < > [email protected]> wrote: > >> 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. >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > > > -- > *Rowan Seymour* > tel: +250 783835665 > http://twitter.com/rowanseymour > > -- *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]
