Fwiw I have been able to clone the htmlformentry project with Git GUI, but when I try to import htmlformentry with EGit I get the following error:
Steps to reproduce: 1) Eclipse->File->Import... 2) Select Git->Projects from Git 3) Select "Clone" 4) Set "URL" to https://github.com/OpenMRS/openmrs-module-htmlformentry 5) Enter my Git username and password 6) Click "Next" Get error message "Cannot list the available branches. Reason https://github.com/OpenMRS/openmrs-module-htmlformentry: https://github.com/OpenMRS/openmrs-module-htmlformentry/info/refs?service=git-upload-pack not found. Anyone know what I am doing wrong here? Thanks, Mark From: [email protected] [mailto:[email protected]] On Behalf Of Rowan Seymour Sent: Tuesday, November 15, 2011 5:15 AM To: [email protected] Subject: Re: [OPENMRS-DEV] FW: HTML form entry changes 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]<mailto:[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]<mailto:[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]<mailto:[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]<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 -- Regards, Kishore Kumar Yekkanti. ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list -- Rowan Seymour tel: +250 783835665<tel:%2B250%20783835665> http://twitter.com/rowanseymour -- 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]
