Week 1 & 2

Good Evening everyone,

                It has been an hectic first week so my the blog for the first lab has been delay all the way to today. So this blog will contain both Lab 1 material about submissions to open source communities, as well as Lab 2 about my benchmarking Lab.

Lab 1 - Open Source Community Submission

                For this Submission I have to chosen to look at Mozilla Firefox Bug Fixing Submission method and the proper way to submit patches to the Linux kernel. This Lab submission is separate into those two part respectively.

Mozilla Firefox

                To submit a bug fix  to Firefox anybody can just needs to follow the instruction listed on their website at : http://codefirefox.com/. For the purpose of this write up however I will summarize the content so it can be contrasted to submission to the Linux Kernel.

                To submit a bug fix to Firefox, one can access their  database of bug needed to be fixed simply by signing up on the website with a free Bugzilla. A default account will allow access to all the bugs Firefox is currently having as well as the ability to post comments on the forums. It does not give access to the source code for working on the bug.

                In order to be able to access those configuration file, one can just post on the forum in the specific  bug page the interest in working on the bug. Then someone who has permission to access those file will assign you as the current assignee to the bug therefore allowing you access to the configuration. According to the website this process would not take more than 24 hours. Once you have finish working on the bug you just upload your code to the forum where it will be process by the main staff and other contributors before been implemented into Firefox.

                Now if you are a regular on Firefox, you can take it to the next step to be able to edit permissions and email: bmo-perms@mozilla.org. In the email that you would send to them it should contain two bugs you have already worked on and fixes, or three bugs you wish to be working on but could not because of the lack of permissions. Once those permission are unlock, you should be able to assign yourself and other as assignee for bug fixes.

Linux Kernel

                To submit patches for the Linux kernel, just like for Firefox, one can just follow all the instruction listed on their website at: https://www.kernel.org/doc/Documentation/SubmittingPatches. I will be however summarizing the process underneath for purpose of completing this lab submission.

                After creating your patch in linux,(using the proper command) load it into a tar file using the proper commands. Then you must write up a report with the list of changes you have made. Be specific about it and make sure to include all details such as will only work with certain driver, or previous patches, etc. Then make sure to style check the changes, make sure the email or description is plain text. Then send an email to one of the maintainers, you should receive back and email. If not feel free to send the patch to the Linux kernel developer's at : linux-kernel@vger.kernel.org. Then once the community has your patches in hand it will get review by other developers. In any case of patches the final decision on including your patch will be made by Linus Torvalds.

Lab 2 - Baseline Builds and Benchmarking

                For lab 2, our pod did not manage to properly finish the entire lab in time. We did manage to start  doing a baseline for PHP compiling time on the x86 architecture machine.  What we did manage to do was download PHP, install all the library necessary to compile PHP and then load up a test code for it on the x86 machine. We did not manage to get enough data to have a proper baseline, not did we have the time to benchmark it to the ARM machine.

                The commands we have used are all listed below, and are the result of our pod collaboration:

# wget -O php-5.6.6.tar.bz2 http://ca1.php.net/get/php-5.6.5.tar.bz2/from/this/mirror

#./configure \

--prefix=/usr/local/php \

--enable-mbstring \

--with-curl \

--with-openssl \

--with-xmlrpc \

--enable-soap \

--enable-zip \

--with-gd \

--with-jpeg-dir \

--with-png-dir \

--with-mysql \

--with-pgsql \

--enable-embedded-mysqli \

--enable-intl \

#make

#make install

Then the code we ran to attempt to baseline the compiling time was the following:

#time php -r 'for($i = 0; $i < 1000; $i++){echo "hello";}'

In which we tried to time the amount of time it takes for php to run the command a 1000 times.

                Hopefully this can be a good point where  our pod can continue working from in the future to do baseline builds and benchmarking.

                If there is anything you feel can be improved, please feel free to comment and I will try my best to fix it next time I blog. Hopefully this will be different by the end of this course, I look forward to your responses.