Changes

</pre><br>'''Bug Fix ThunderBird Lab'''<br>The following is the patch file that was generated by conducting a CVS diff -u8p . > tbirdPatch.txt. Here are the contents of that patch file <br><pre>? tbirdPatch.txtIndex: streamconv/converters/mozTXTToHTMLConv.cpp===================================================================RCS file: /cvsroot/mozilla/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp,vretrieving revision 1.85diff -u -8 -p -r1.85 mozTXTToHTMLConv.cpp--- streamconv/converters/mozTXTToHTMLConv.cpp 11 Mar 2007 00:17:00 -0000 1.85+++ streamconv/converters/mozTXTToHTMLConv.cpp 11 Nov 2007 18:03:20 -0000@@ -181,17 +181,17 @@ mozTXTToHTMLConv::CompleteAbbreviatedURL if (pos >= aInLength) return; if (aInString[pos] == '@') { // only pre-pend a mailto url if the string contains a .domain in it.. //i.e. we want to linkify johndoe@foo.com but not "let's meet @8pm" nsDependentString inString(aInString, aInLength);- if (inString.FindChar('.', pos) != kNotFound) // if we have a '.' after the @ sign....+ if ((inString.FindChar('.', pos) != kNotFound) && (inString.Find("..", 0) == kNotFound)) // if we have a '.' after the @ sign.... { aOutString.AssignLiteral("mailto:"); aOutString += aInString; } } else if (aInString[pos] == '.') { if (ItMatchesDelimited(aInString, aInLength,</pre><br>Bug filed on bugzilla. [http://landfill.bugzilla.org/bugzilla-3.0-branch/show_bug.cgi?id=6031 Bug 6031]

To finish off I would say many important points were covered by this speaker; especially the reasons for the reading code, the purpose of reviewing and the constant inference on quality of the code. Documentation was yet another major emphasis made by this speaker and in my opinion I believe this is a very important thing for any coder to practice. Documentations is the only link that other have sometimes when people are trying to understand and decipher some other persons code. Nothing that happened in this talk changed my view of open source or what the entire community is all about. <br> <br>'''Mike Beltzner’s designing for and with community'''<br>I must say I have never attended a speaker’s talk that was filled with so many “weeeeees” and other funny expressions as Mike Beltzner’s talk about designing for and with the open source community. A very intriguing speaker who captivates you with his interest, presentation style and overall funny demeanor; something I think is very attention grabbing for me at the least.<br><br>I remember the first and foremost thing Mike talked about, he said designing in open source is not something that is ready for primetime. I must honestly say at first I had my doubts about what he was referring to in that statement; but then it occurred to me; maybe it is the way of how designing and implementing is done in the open source community drawing parallels to cathedral and the bazaar. In today’s world of organization and control the bazaar type of software development is yet to be embraced by the major corporations and companies; and in my foreseeable future at the least I do not see this trend of developing software changing. Maybe this is what Mike was referring to when he said “Designing in open source is not something that is ready for primetime” I could be wrong.<br><br>One of the major things Mike talked about was embracing the chaos of open source. There are always many different perspectives out there and many different ideas on how people want to help out. Some might just be condescending while others are generally out to help the new comers feel at home. He then went on to talk about the three main points of designing for and with the open source community. They were as follows:<br>*Listen to your community (because if you do not do so, they will get alienated by the lack of listening and therefore grow to hate the product)*Lead your community (setting examples and most importantly standards by which work should be done in is key and very important in this type of open source environment)*Let the community play and experiment (in order to build a strong community support and gain loyalty the company must allow the community to fully take apart and understand the underlying code base of the software. This will allow for people to experiment with their own knowledge and therefore creating their own extensions or add on that can benefit the rest of the community or in some cases even the original creators of the software).<br><br>Mike also pointed out a key point that caught my attention; he said thirty seven percent of code that came into Firefox between November 2006 and April 2007 were from outside contributors and not from within the company developers. He also pointed out certain factors that are part of the open source community and people should learn to accept this. They were as follows:*There are no easy buckets (meaning like every company or organization no one will give you credit right away; credit has to be earned and one has to prove themselves as a worthy contributor)*Strong leadership structure (major contributors and creators of the code should be strong in their leadership of their community otherwise the community will loose strength and support)<br><br>Mike seemed to stress a lot on “listening to the community”. He talked about providing multiple well defined channels where people can actually come together, share ideas and contribute their code and feedback to others. But he also bought about another concern that has been around in every community not only the open source community. With this sort of open listening system per se comes the reality of camps. Camps are when people begin to form into groups and most of the times groups of people tend to agree and disagree with other groups of people. Usually these types of camps have a leader who argues their side of the argument against the other leaders of other camps; this often leads to people being one sided in their view or aligning themselves with one camp or side. Also people tend to make offensive or condescending remarks towards others in different camps that are not in agreement with their camp. Mike said the best way to get around this sort of camp propaganda or misinformation is to do the following:*Educate yourself of the different topics out there that the camps are disagreeing over.*Find the people who are making the smart comments and read what they have to say instead of listening to anyone and everyone.<br><br>Another topic Mike touched on which was interesting was how to bring order to chaos. Again drawing parallel to the cathedral and bazaar. Mr. Beltzner said some ways of keep order amidst the chaos is to*Create small teams, led by strong contributors and give them responsibilities to complete.*Always offer data to elevate discussions about topics of concern or importance.*Never treat disagreements as an adversarial notion. Instead look at it as a negotiation to attain the ultimate goal.*Use an onion layer model for releasing (always get different levels of input from the community and analyze different ways of solving a problem before committing to a release; at least that is what I gathered from the explanation he gave)<br><br>Mike Beltzner also talked about a very interesting extension which I have not heard about called CoScripter. From my understanding this is an extension that is used to record actions on the web and then share them with other. If my understanding is correct this extension writes script to automate certain web actions in order to make the user experience a quick and efficient once. Also CoScripter displays the actions in readable text format. I maybe wrong in this interpretation but this is such a useful extension to have in my opinion.<br><br>'''Conclusion'''<br>After attending these two talks, I can say most of my perceptions and views of open source were unchanged and nothing major really was told or occurred in order to obscure my view of what open source is today. I must say Dave Humphries suggestion on reading the cathedral and the bazaar was quite the best way to start of this course; because it gives a beginner a clear idea of what to expect in this sort of development environment.<br> <br>When comparing and contrasting the ways the two speakers conducted their talks; there seem to be more similarities than there were differences. Both speakers were clear in touching on the order to chaos points. Both shared a very great enthusiasm for what they were doing and how they were helping the community in doing what they were doing. The only noticeable difference was Mike Beltzner took a very casual and funny approach to his talk where as Benjamin Smedberg took a more formal approach to his talk. Both these speakers are ‘Gurus’ in their own right in what they do; definitely a very worth while experience for me as a beginner.<br><br>This FSOSS imposium was a definite eye opener to me; it showed me the type of leaders who are out there striving to keep the open source community up and alive. It also opened me to the many different facets and possibilities there are in this open source community and how these facets and their founding principles can help in the improvement and spreading of technology, learning and knowledge to the under privileged communities of the world we live in.<br>