Thursday, October 18, 2012

Shifting full time to 64-bit

Hmmm. This one has been on the stove for a long time. But I just didn't have the time. Finally though this week I got some free time to perform some much needed system maintenance and so I downloaded Ubuntu 12.04.1 LTS 64-bit ISO, used Usb-creator to create a bootable USB and installed it on a partition holding 10.04.1 Ubuntu.

Right now I'm installing all the required programs, servers and what not. I think it will be a week by the time I fully shift to this 64-bit Ubuntu.

Update 21 10 2012: I have ended up with a botched install of Elementary Daily Build; small relief is that the desktop is working but remastersys is unable to create proper ISO's. I think the nvidia driver is to blame, but I'll try to work through this. If it works then fine else I'll have to restart with a stock daily build. (Groans!!!!)

Update 2 23 10 2012: Okay, finally I have readied the new system last night. And I think it's running beautifully. So I'll test it for a week or so and then get back here to share my experiences in the review post! I know that's been pending for what seems like forever!!!


Sync has become a popular word these days.

oh, yeah. I have not forgotten about the elementary Luna review. Just working on that.

Sent from my Windows Phone

Sunday, October 14, 2012

Elementary OS Luna Daily Build Review coming soon

I have been using Elementary OS Luna for about a fortnight and I think elementary has reached a stage where I can safely review it. I had refrained from this because like they say "it ain't done yet and sou should wait for the pickle to get ready or it won't taste the best." So with elementary the pickle is yet to get prime, but whatever stage I have in my hands is good enough that I'm going to be telling you about it.

On a side note, this is going to be a OS review from me in quite some time. The reason being I am quite exhausted these days thanks to the Six Day week I have to bear at my current organization. Well, that as it may be, still I find elementary enough exciting that I'll be putting aside some energy for this task.


Update 23 10 2012: Due to some problems persisting with 64-bit Luna Live CD and partly my stupidity I have managed to lose the screen caps and half the review I had written. Luckily the system is up now. So I think I'll test all the parts again - it's 64-Bit beast now! - and I'll get back with the promised review. I'll also share the software compilation. The complete ISO runs to 1.1GB as of now. And I think software wise it's almost complete.

Friday, October 12, 2012

Why so many login sessions?

Recently I was working on some maintenance stuff for some crystal reports. And I stumbled upon a peculiar problem.
The report had 4 sub reports in it and it was running out of available login sessions in about 10 runs. The problem was I'm at average level when it comes to .net and a newbie to crystal reports. So I'm just discovering things and half the time I don't know where I'm going. That of course sucks but I can't help it. The workload is more than enough that every day I go to my rented place completely exhausted and badly in need of sleep.
Anyway that's beside the point. The thing is that I didn't even know what is causing the "no more login sessions available" error. So after some discovering on the internet I learned some things about Oracle logins and login sessions. The solution seemed very simple - increase maximum number of login sessions in oracle.
But I knew I have to fix the root cause of this. And the root cause is in the report and the code that generates it.
So I'm again in the code looking for things where there might be a new session getting created. Well, after some careful sniffing I couldn't find anything in the functions block. Well, what now. Then I remembered that I have some more functions pulling data that reside in another source file and I am yet to check them. So after a furious search I found the culprit functions.
So after carefully editing the things and making everything work right, I have the report working much better.
Still something is not alright. I'm still losing one session let run and the connection pool is exhausted by 30th run or so. But luckily for me nobody is going to use it for that long so at least I can push it to production.
Good job!

Sent from my Windows Phone

Friday, October 5, 2012

[from] Burning down critical bugs

Link to Original Article:

I have copied the article instead of just providing the link because just in case the article is lost (maybe deleted from original source or link changed... ) it's still available here.

I have been analysing Launchpad's critical bugs to track the Purple squad's progress while on Launchpad maintenance duty. In January of 2011, the Cloud Engineering team nĂ© Launchpad Engineering team was reorganised into squads, where one or more squads would maintain Launchpad while other squads work on features. This change also aligned with a new found effort to enforce the zero-oops policy. The two maintenance squads had more than 332 critical bugs to close before we could consider adding features that the stakeholders and community wanted. By July 2011, the count dropped to its lowest point, 250 known critical bugs. Why did the count stop falling for fifteen months? Why is the count falling again?

Charting and analysing critical bugs

Chart of Launchpad's critical bugs since the formation of Launchpad squads and maintenance duties
The chart above needs some explanation to understand what is happening in Launchpad's critical bugs over time. (You may want to open the image in a separate window to see everything in detail.) Each iteration is one week. The backlog represent the open critical bugs in launchpad at the start of the iteration. The future bugs are either bugs that are not discovered, not introduced, or reported and fixed within the iteration. The last group is crucial to understand the lines plotting the number of bugs fixed and added during the iteration. We strive to close critical bugs immediately. Most critical bugs are reported and fixed in a few days, so most bugs were not open long enough to be show up in the backlog. The number of bugs fixed must exceed the number added to make the backlog count fall. You can see that the maintenance squads have always been burning down the critical bugs, but if you are just watching the number of open bugs in Launchpad, you get the sense that the squads are running to just stand still.

I use the lp-milestone YUI widget to chart the bugs and analyse the our progress through the critical bugs. It allows me to summarise a set of bugs, or analyse a subset by bug tag.

Launchpad maintenance analysis -- driving critical bugs to zero

Though 22 bugs were fixed this past week, 14 were added, thus the critical count dropped by 8. The last eight iterations are used to calculate the average bugs closed and open per iteration. The relative velocity (velocity – flux) is used to estimate the remaining number of days to drive the count to zero. When the Purple squad started maintenance on September 10th of 2012, the estimated days of effort was more than 1,200. In just three weeks, the number has fallen dramatically. The principle reason the backlog of critical bugs has fallen is that the Purple squad is now giving those bugs their full attention, but that generalisation is unsatisfactory.

Why is the Purple squad so good at closing bugs in the critical backlog?

I do not know the answer to my question. The critical backlog reached its all-time low of 250 bugs with the release of the Purple squad's maintenance work in July 2011. There was supposition that  Purple fixed the easy bugs, or that the fixes did not address the root cause, so another critical bug was opened. I disagree. The squad had no trouble finding easy bugs, and it too would have been fixing secondary bugs if the first fix was incomplete. I can tell you how the squad works on critical bugs, but not why it is successful.

I was surprised to see the Purple squad were still the top critical bug closers when it returned to maintenance after 15 months of feature work. How could that be?  The squad fixed a lot of old timeout and JavaScript bugs in the last few months through systemic changes — enough to significantly affect the statistics. About 600 critical bugs were closed while Purple squad were on feature work. The squad closed 210 of those bugs. 60 were regressions that were fixed within the iteration, so they never showed up in the backlog. 70 critical bugs were fixed because they blocked the feature, and 80 critical bugs were because Purple was the only squad awake when the issue was reported. The 4 other squads fixed an average of 98 bugs each when they were on maintenance. The Purple squad fixed more bugs then maintenance squads on average even when they were not officially doing maintenance work.  The data, charts, and analysis always includes the Purple squad.

I suspect the Purple squad has more familiarity with bugs in the critical backlog. They never stopped reading the critical bugs when they were on feature work. They saw opportunities to fix critical bugs while solving feature problems. I know some of the squad members are subscribed to all critical bugs and re-read them often. They triage and re-triage Launchpad bugs. This familiarity means that many bugs are ready to code — they know where the problem is and how to fix it before the work is assigned to them. They fixed many bugs in less than a day, often doing exactly what was suggested in the bug comments.

During the first week of their return to maintenance, about 30 critical bugs were discovered to be dupes of other bugs. Though this change does make the backlog count fall, it also revised all the data, so the chart is not showing these 30 bugs as at all now. The decline of backlog bugs does not include dupes. While the squad was familiar enough to find many bugs that they close in a single day, they were not so familiar as to have known that there were 30 duplicate bugs in the backlog when they started.

Most squad have only one person with DB access, but the Purple squad is blessed with 3 people who can test queries against production-level data. This could be a significant factor. It is nigh impossible to fix a timeout bug without proper database testing. Only 13 of the recent bugs closed were timeouts though. The access also helps plan proper fixes for other bugs as well, so maybe 20% of the fixed bugs can be attributed to database access.

Maybe the Purple squad are better maintenance engineers than other squads who work on maintenance. For 28 months, I was the leading bug closer working on Launchpad. I closed 3 times more bugs than the average Launchpad engineer. I am not a great engineer though. My "winning" streak came to a closed shortly after William Grant started working on Launchpad full time; he soundly trounced me over several months. Then he and I were put on the same squad and asked to fix critical bugs. Purple also had Jon Sackett, who was closing almost 2 times the number bugs than the other engineers. I don't think I need to be humble on this matter. To use the vulgar, we rocked! Ian was the odd man on the Purple squad. He was the slowest bug closer, often going beyond our intended scope to fix an issue. Then Purple switched to feature work…Ian lept to the first rank while the rest of the squad struggled. Ian fixed almost double the number of Disclosure bugs than other squad members. The leading critical bug closer on the squad at the moment though is Steve Kowalik. This is his first time working on maintenance. His productivity has jumped since transitioning to maintenance.

I can only speculate as to why some engineers are better at maintenance, or can just close more bugs than others. A maintenance engineer must be familiar with the code and the rules that guide it. Feature engineers need to analyse issues and create new rules to guide code. I did not gradually become a leading bug closer, it happen in a single day when I realised while solving one issue that the code I was looking at was flawed, it certainly was causing a bug, I knew how to fix it, and with a few extra hours of extra effort, I could close two bugs in a single day. Closing bugs has always been easy since that moment.

I believe the Purple squad values certainty over severity and small scope over large scope when choosing which critical backlog bugs to fix. I created several charts that break the critical bugs into smaller categories. I suggested the squad burn down sub-categories of bugs like regressions, or 404s. The squad members are instead fixing bugs from the entire backlog. They are choosing bugs that they are certain they can fix in a few hours.  I think the squad has tacitly agreed to fix bugs that are less than a day of effort. When this group is exhausted, they will fix issues that require days of effort, but also fix as many bugs. The last bugs to be fixed will be those that require many days to fix a single bug. Fixing the bugs with the highest certainty reduced our churn through the critical bugs, there are fewer to triage, to dupe, to get ready to code.

The Purple squad avoids doing feature-level design and effort to fix critical bugs. Feature-level efforts entail more risk, more planning, and much more time. There is often no guarantee, low certainty, that a feature will fix the issue. A faster change with higher certainty can fix the issue, but leaves cruft in the code that the engineers do not like. Choosing to do feature-level fixes when a more certain fix is available indicates there is tension between the Launchpad users who have a "critical" issue that stops them from using Launchpad, and the engineers who have a "high" issue maintaining mediocre code. I contend it is easier to do feature-level work when you are not interrupted with maintenance issues. When the Purple squad does choose to do feature-level work to fix a critical, they have a list of the bugs they expect to fix, and they cut scope when fixing a single bug delays the fix of the others. The Launchpad Answers email subsystem was re-written when other options were not viable, there we about 20 leading timeouts represented by 5 specific bugs to justify 10 days of effort to fix them.

The Purple squad is not unique

Nothing that I have written explains why the Purple squad are better are closing critical bugs. All squads have roughly the same skills and make decisions like Purple. Maybe the issue is just a matter of degree. If the maintenance squad is not closing enough bugs to burn down the backlog, their time is consumed by triaging and duping new critical bug reports. Familiarity with Launchpad's 1000′s of bugs is an advantage when triaging bugs and getting a bug ready to code. Being able to test queries yourself on a production-level database takes hours or days off the time needed to fix an issue. Familiarity with the code and the reasoning that guided it increases the certainty of success. The only domain that Purple is not comfortable working with is lp.translations; the squad is comfortable changing 90% of Launchpad's code. There may be correlation between familiarity with code, and the facts that the squad members participated in the apocalypse that  re-organised the code base, and that some have a LoC credit count in the 1000′s.

Monday, October 1, 2012

intermittent cellular

For last one week I have been plagued with intermittent cellular connection issues. I have switched to Uninor 2G and the plan is 6 GB data for 90 INR ( that's about $1.7 ) Its really cheap when considered to Airtel which gave only 1GB 2G data for INR 98.
Anyway tye problem is that the connection has not been consistent. Sometimes it would work great giving me a speed of 15-20KBps which is commendable for 2G. But then sometimes I start losing data packets and so everything starts crawling. The drop is sometimes as high as 50%. This I found out using ping. So I'm going to see for next couple of weeks if they get their S••• Together or I'll have to find another provider.
I wish I had a 500 - 700 INR budget for internet but I don't have much use for internet beyond mails and some news. Everything else comes under pastime. So I don't want to spend so much money on pastime. I would rather go to a walk when I'm bored. Or go to a nearby temple for that matter. :)

Sent from my Windows Phone