I'm presenting the contents in LDSC 12 poster session. 11:50 a.m.-12:30 p.m.: "Gallery opening" in Zoller Gallery in the Visual Arts Building.
Attending Open Source Bridge 2012 (OSB) was an experience beyond my original expectation. Besides learning about new technologies and the trend in the field, I am very impressed by how the conference is organized, whom I met in the conference, the insights of various technologies I learned from the conference, and the spirit which drives all these.
Normally a technology conference is organized by either a cooperation or an institute, but OSB is totally organized by volunteers, most of whom are open source software developers themselves. Now here is something very special about open source developers. These are the people who have donated their time and intelligence to collaborate with others on a projects that benefit others. I think this conference itself is just another project of these open source veterans.
Talking to some of the organizers, I learned quite a few tips about their workflow, team organization, and project management techniques. Motivating volunteers by creating values for everyone is indeed an art that is worth learning.
Come to think of it, our symposiums and summer camps also call for volunteers and the main organizers have always open channels for ideas. I feel that we share some open source spirit here in ETS.
The last day of the event is the unconference day. The agenda is to be decided on the beginning of the day by the participants together. I think it's a great in two ways: 1. it involves the participants to determine what they want collectively; 2. it gives everyone an opportunity to discuss their ideas with all the great minds already being there. Many sessions are raw ideas waiting for participants to add ingredients to cook.
Insight behind technologies
This conference gathered open source developers, project managers, and enthusiasts, as well as some famous developers in high profile open source projects such as Wikimedia, Firefox, Drupal, etc. and companies such as Mozilla, Wikipedia, Google, Twitter, etc. This makes it a great opportunity to learn about the latest development of various projects, the challenges they are facing in managing their projects, and the solutions they come up with.
The problems sometimes are purely technical so they have to resort to latest technology or new creative ways of using existing technologies (which is a familiar practice in our blog team here).
However, a lot of problems are not technical. They often need to come up with a way to lead the volunteers to reach to a consensus so such large number of developers can continue working in the same direction.
I also see how small projects can potentially turn into a game changers in such conferences. People openly share their ideas and a bunch of coders would sit together impromptu to hack away a problem.
Besides the "professional" characteristics mentioned above, this conference, held by this particular group of people, surprised me in a few ways.
I had never experienced any conference that is totally vegetarian. All food is clearly labeled whether it contains gluten or soy. Finally there is a conference where I could have enough good, healthy, and tasty food. (I am a vegetarian.)
There are all sorts of developers I saw here: those who don't wear shoes (in life), those who bike and walk instead of drive, those who bring their own mug, those who walk around to invite shy fellows into a conversations, those who always think about how to help newbies, etc. There is a common theme: these people believe that the future is in the hands of people who practice what they believe, and that by collaboration, we can really make a difference.
A few of them had donated their time to Code for America, and I've met some who is doing a healthcare version of it.
These are not only dreamers, but doers.
Open Source Spirit
This ted talk expressed the spirit of open source very nicely.
a. The evaluation of a tool, how to choose the best tool for one's purpose, and how to make a tool work effectively in a presentation.b. The concept of the markup language, and the experience of thinking in terms of contents and forms.c. How to learn something new from reading technical documents.
a. When preparing a presentation, knowing the resolution of the projector is important. Students prepared their presentation on their laptop with full resolution, but the projector in the classroom could not display the pictures in its entirety.b. Google Earth heavily relies on the internet to load its map data, so it is crucial to have a stable and fast internet in the room. Reserving a computer lab may be a better in this case.c. Google Earth's tour mode is still buggy. Any file operations performed while the tour mode panel is opened will crash Google Earth. Let's hope Google fixes that one some time soon.
And let's say we want to make a change to the function so the system will call our version instead.
Namely, we only want statement 4 to be executed but we'd like to keep statement 1-3 around for future reference.
And now the upstream base of the original code has an update:
Namely, they added statement1.5 and statement 5.
Supposedly, we should get a conflict since the semantics of the code has changed; however, since git deals with only chunks of diffs, and the determination of conflict has to happen onto the same chunk of code, i.e. consecutive lines, git will not see this as conflict waiting to be resolved. It gives us the wrong merge result (suppose we don't want statement 5 in our environment):
Let's look closely at what happened here. First, in MT2, there are two sections that got changed from VERSION MT1, i.e. the addition of statement1.5, and the addition of statement5 are simply two additions. In PSU1, we changed the function name from func to _func, and then inserted brackets and another function name between statement 3 and 4. So from git's point of view, the first chunk of diff is the change of function name (from func to _func. It's independent and will pass the automatic conflict resolution. The second chunk of diff is the insertion of statement 1.5. Same, it's independent and will pass automatic merge. The 3rd chunk is insertion of two brackets and a function name -- independent and will pass check. The 4th chunk is insertion of statement 5 -- independent and will pass check.
There is no way that git will know that we only want statement 4 to be execute and statement 5 is irrelevant to us.
There are two potential solutions:
The first solution is the common standard. Don't do any trick like changing the function name; instead, just delete the original code and write out our target:
git will not resolve the conflict but at least it'll tell us that it can't so we can do it manually. The principle here is: when we have a mod that changes program logic like this, we want to make sure that our mod will create conflict.
The second solution is also about creating intentional conflict. We can comment out the original code and add our mod after that, so it looks like we both added and deleted something and will require manual intervention.
The manual merge will still be a lot of work, but at least git won't create hidden problems that lead to infinite debugging time.