1
edit
Changes
m
no edit summary
this.mTabContainer.childNodes[i]._selected = false;
}
</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]
== FSOSS REPORT FOR DPS909 ==
*Look for code which was changed recently or something that has being undergoing consistent change<br>
<br>
Benjamin also told us about checking version control systems, if I remember correctly, these are systems that are in place that people can use to go back in time and look through the code changes as they progressed through time. Then we moved on to “Reading to Learn” or reading to code to learn its layout, structure, and purpose. The objective of this reading to learn method is to understand the big picture, the technologies, functions, object models and function names being used in the system. Benjamin also suggested a programmer should read the unit tests if it is available.<br> <br>Another part of learning the code is to learn to write test programs that will work with or add to the main code base. These little test programs or code inserts will help the user get a better grip over what a certain function or code set does. Mr. Smedberg repeatedly stressed in this community and this type chaos it is crucial to ask questions. Not everyone can understand the programming style or the purpose behind a certain code set or functions; so in order to clarify the doubts or misconceptions it is best to ask questions and get an answer from the community. Another point Benjamin stressed on was that code reading should be a “social exercise”; it should not be viewed as a process or in the word of Mr. Smedberg himself “It should not be just some geek, sitting in his basement reading code and understand it, people should take a general interest in it and move beyond just coding by themselves but do it in groups or as an activity with friends”.<br><br>Mr. Smedberg then got into the reasons why people bother with code reading. These reasons are as follows:*Code reading is necessary to insure quality in code*It creates a culture of responsibility where people who participate in any form or nature are responsible for whatever they contribute; good or bad.*Reviewing code allows for mentoring of newer programmers and allows for more participation of others by inviting people into the community.*Gets more involvement. When multiple people get to know about the code, it removes the dependencies on one person alone knowing the intricacies of the code.*The main purpose being for code reading and reviewing is for better human comprehension, better readability and better maintainability.<br><br>Mr. Smedberg completed these reasons by saying something that really stood out in my opinion. He said everyone is going to have problems therefore never try to solve everyone’s problems because there are some problems that are too complex or too trivial to be solved. He also cautioned to be on the watch out for what he termed as “Code Astronauts” people who try to do too much or try to be perfectionists. He (Benjamin) later on went on to the types or code reviewing and reasons behind it. Some of the major types of reviews he discussed were: (in no order)<br><br>'''Goal Review:''' What is the problem with code in the system? Is it worth solving the problem? Should an entire system be rebuilt in order to sort out one bug? What are the tradeoffs in achieving the goals? These were some of the questions Mr. Smedberg addressed under the goal review criteria.<br> <br>'''Maintainability Review:''' the main concern under this review is coder understanding of the already existing code base. Documentation is key in this stage and every piece of code should be documented well. Making sure the code is consistent or correct through out the system and ensuring there are no warnings or errors in the code.<br><br>'''Security Review:''' If the code is being exposed to unknown and or un-trusted people; make sure there are proper function wrappers in order keep the data well protected.<br><br>'''UI Review:''' Make sure the user interface does what the user expects it to do and is well placed in areas where users will check for it. Make sure the font size and type of text used is consistent through out the UI layers and is easy to understand.<br><br>'''Integration Review:''' Make sure the modules work with each other properly, and make sure all the dependencies are addressed in the integration review. Also check to see if the final product is localizable and do a review of the documentation at this stage to make sure everything is documented well for the user. This documentation is more of help documentation not code documentation as end user will be highly unlikely to be looking at code documentation more so at documentation on what the systems key functions are and how they can be executed or called.<br><br>'''Testing Review:''' In this type of review a check is done to see if there are tools to evaluate the code. Check for code inconsistencies and or incorrect function calls, placements, or other code related issues.<br><br>Mr. Smedberg also talked about “using the experts” which correlates to the previous mention of asking questions in this report. Always ask the experts if something is confusing or beyond a beginners understanding. From his talks I gathered Benjamin Smedberg’s opinion of the best thing that is part of Mozilla is the extension infrastructure which is in place.<br> <br>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><br>
== Contact Info ==
<pre>
