Roger, I don't think we need to disagree. Part of migrating toward DCVS is to evolve toward distributed programming, where programmers don't need to ask permission to try something out (they just try it out in their own space… if it works, they submit a pull request to get it into the main codebase; if it fails, it silently fades away). This reduces barriers for developers who wish to contribute. I completely agree with you, that the onus fall on OpenMRS leadership to ensure that we're bringing organization to the chaos and making it easy for the community to find the "mainline" as you call it, communicate conventions, etc. While we can adopt a convention that "mainline" code has to be under the OpenMRS organization in git, I don't believe that's the only option as long as it's easy to tell what's been vetted.
Cheers, -Burke On Tue, Mar 13, 2012 at 10:29 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < [email protected]> wrote: > Burke, I’ve got to disagree with you on this. In this “year of > documentation”, how can you say it’s more important that “developers be > more agile”? It’s already really easy for people to get way ahead of the > curve without being responsible for the impact of their meanderings. The > MRS does not exist for the benefit of the developers, it exists to meet > patient care goals. I think the thread at the Implementers Meeting was > that people wanted more usability out of the box, i.e. more attention to > having things work together and be offered as prepackaged feature sets, I > didn’t hear anyone say that the programmers’ creativity was being stifled. > We already have a really steep learning curve for new developers, and to > add the effort to integrate the disintegrated is really asking too much. > I’ve got no problems with moving to git, I just want to make sure that > there is a main line that represents what OpenMRS is and that stuff gets > into the main line by compliance with various standards. If I want to > write something that is OpenMRS-ready, it ought to be clear what that means > and that changes to what that means goes through the OpenMRS design > process. It ought not be that because one or more of the core folk know > that another person has some coolio stuff on their hub that that can block > or break something that is going or has gone through the OpenMRS process. > I’m afraid that “agile” just means “programmer-centric” and it has proven > itself to be counterproductive.**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Burke > Mamlin > *Sent:* Sunday, March 11, 2012 4:02 PM > *To:* [email protected] > *Subject:* Re: [OPENMRS-DEV] git conventions**** > > ** ** > > Darius,**** > > ** ** > > Regarding conventions for git repository locations… either is fine. I'm > fine with repositories "earning" their way into (or out of) the openmrs > account through use or lack of use. The only potential downside of moving > repositories around is breaking links (from wiki pages, emails, OpenMRS > Answers, CI/maven scripts, etc.), but that's a minor/trivial issue. The > ability for developers to be more agile is way more important, IMHO. Over > time, if yours or any other module becomes largely managed by OpenMRS, then > folks may prefer moving it into the openmrs organization in order to share > the management burden; but, starting out under personal accounts is a more > natural DCVS approach.**** > > ** ** > > Cheers,**** > > ** ** > > -Burke**** > > On Sun, Mar 11, 2012 at 2:13 PM, Darius Jazayeri <[email protected]> > wrote:**** > > Hi Burke,**** > > ** ** > > I'm working on moving the 2.x UI Framework code into a module, and I > started using git for this, as I was working on the plane and wanted to be > able to locally commit, etc.**** > > ** ** > > Question: what's the right convention for where should I initially publish > this?**** > > ** ** > > Option 1: I put it at github.com/djazayeri/openmrs-module-uiframework. At > some point OpenMRS may actively decide to own this module, and clones it.* > *** > > ** ** > > Option 2: I put it at github.com/openmrs/openmrs-module-uiframework, > assuming that OpenMRS is going to want to own this.**** > > ** ** > > I think option 1 is right (and this would work equally well for me as for > non-core-devs), but wondering if you have any thoughts?**** > > ** ** > > -Darius**** > > ** ** > ------------------------------ > > 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]
