Saturday, January 3, 2009

Myth 4: Longer release times equals better quality applications.

Sorry to say is one of the largest and very badly wrong ideas.

So a project releases every 2 months doubling that to 4 months really does not make a difference. To really understand how to do it correctly is looking at the Linux Kernel. Distributions failing to hit release timetables closely could also pay to read this.

Linux Kernel release a new version every 3 months. Reason why the can do releases so fast is Linux Kernel Development model. No patch going into a release goes straight into final Linux Kernel then out to Public. All patches have to go through a peer vetting process. Most cases at least 3 different people have signed off that the code is of good quality and passed there tests.

Out of that 3 months over 2 months is quality checking of the patches that got approved. Any patch/alteration that missed the 2 week windows for include in the next Linux kernel goes into a side tree for testing. If quality is not good enough it don't merge into the main Linux kernel. Some patches have taken over 2 years before they eventually make it into the Main kernel. Yet in that time there have been 3 monthly releases.

Then there is a kernel testing frame work to make sure no errors have slipped in.

Theory you could ramp the Linux kernel up to daily released without dropping quality. The over lap of the testing process with the release process makes it possible. Patches that get released into the Linux kernel have been tested way more than 3 month release cycle.

Most Distributions have made the problem of quality control many times harder due to there packaging systems. Where Linux kernel can do a incremental update with 2 parts using 2 different systems to the same job side by side packaging systems cannot. Deprecated functions in the Linux kernel is an example of this. Function is Deprecated but is still around for the drivers that use it.

Distributions need to be able to do Deprecated dependencies while applications are on the system that have not been tested against the new dependencies those applications allowed to use older deprecated ones. Most distributions cannot do this. There packaging systems have been designed completely with the idea of 1 .so file 1 configuration system and so on. So Distribution are getting overloaded trying to make every application and dependency work with everything else on the system at once.

Basically breach of Quality control maintainers should never be force to rush there quality testing like they are now. If X application is stable with Y dependencies maintainer not happy that replacement dependencies have not been tested enough yet maintainer should be able to delay it. Where maintainers hit hell is delaying Y dependencies from being updated will block other applications from being installed so they get other maintainers on there back or just forced to use the newer dependencies because the older ones are not being provided. This is where the pressure is coming from for Maintainers to rush the Quality control process.

Longer and smoother transition from one distribution version to another is required. Please note the word transition installed version in the transition would be part way between versions. No sudden changes. Sudden changes equals major over load of Quality Control processes. Its like slowing down for school zones it makes sense.

The release time issue is nothing more than a smoke screen covering up design bugs forcing quality controls to be rushed or lack of quality controls put in place.

Lot of work is need to bring Linux Kernel style quality control processes to lots of open source and closed source project out there.

5 comments:

Anonymous said...

Get a darned editor! Your English grammar is so bad that your articles are very nearly unreadable. It's one thing for us to slug our way through reading comments from people with less than stellar grammar, but do we need to have the original article poorly written that way too?

Why don't you ask for a volunteer from among your readers? Simple enough...

oiaohm said...

Simple point I don't see that I have many readers. So I have not asked.

If you want nightmare of having to deal with my grammar issues. Contact me. oiaohm@gmail.com. Yes fixing up my old posts are allowed if you want to.

If I am emailed a corrected version yes I will correct it. I will even nicely give who ever send it to me credit.

Its a evil trade I have to do. Good grammar marks and word scrabbled to unreadable and past what any spell checker will help or readable none.

If I am corrected enough I might improve too. Who knows. Ok would not hold breath on fast improvement this is the best I have been in over 20 years.

Yes at some point I need to get back into the blog configurations and add a email me article grammar corrections button.

Anonymous said...

In an earlier article's comments area you indicate that English is your native language but you clearly are having a tough time putting your thoughts coherently into words. How is it that you seem to grasp the core concepts of what you write about pretty well but then verbally express them so poorly? I would be curious to know where you got your primary education (K-12) from. From experience, my guess in that regard would be that of the "Outcome-Based" American public schools system using the "Whole-Language" method of teaching reading and comprehension.

In response to my earlier post you indicated that you would appreciate me/us sending you corrected versions of your article, or articles. Although I haven't any particularly notable grammatical skills or formal training as a writer, I can usually get my point across, and seriously considered giving you a hand with this.

However, after reading and rereading your article many times in an attempt to wrap my head around what you've written, it's become obvious that this article requires far more than simple corrections of grammar. The very core structure of the article is overly wordy, with all of the important points aimlessly scattered about, making it nearly incomprehensible in total. Further, the only way that this article would actually make any sense would be to change the title from "better quality applications" to "a better quality Linux kernel". Your own summation makes an argument against the very premise of your article's current title.

The body of the article (if properly structured)would make a pretty good argument for why -- because of the particular way that the Linux kernel is developed -- longer release times wouldn't improve the Linux kernel. But, you then posit that "application" developers have a long way to go in this regard because they don't develop their software the way the Linux kernel does, implying then, that longer release times can, indeed, be helpful in attaining better quality for application developers who use their current substandard (non Linux kernel)development protocols/models.

I would have an easier time rewriting your entire article from scratch using an outline made from its salient points, than trying to make sense of what you've written.

Perhaps what you need is to first write an outline, then arrange them in some logical order before you attempt to write the entire piece. Outlines help you ramble on less while helping you keep your eye on the ball better. Then, correcting your poor grammar and minor tweaks to the overall structure would be doable.
Any further points or thoughts?

oiaohm said...

Australian Schools. Yes school is not the issue. There is only so much you can do with a off the scale person with Dyslexia. Funny enough I passed year 12 English. Pure luck really all exams lined up on my really good days. Yes I can do grammar it just increases risk of major stuff up.

Minor Dyslexia shuffle all the letters in words. My problem it extends far worse than that. I can shuffle words in sentences and even blocks of text with blocks of text. Basically type a document that looks like someone encrypted it and read it perfectly fine for about 7 days. Worst nightmare of it is that for a far amount of time after I write something it can appear perfectly fine because my mind corrects it. So yes writing a outline normally does not help. Since when I read it to me it will appear that I have not made error. Even worse listening to it mind can still hide it.

I am a off scale dyslexia who as reformed self to a point of some what functional most of the time. Verbal Written and Hearing all effected. I do enjoy Verbal. 90 percent of all people I meet can understand it yet be really confused how. Say the phonic sounds in the wrong order yet in there mind they think I have said what I wanted to yet then they know the sound don't match up. Only people who cannot are people who don't have any form of dyslexia in there mind. Yes dyslexia everywhere from normal to non functional.

Cover two related and complex topics in there. Really stupid I should have known that was really asking for my mind to play up. Yes it did not miss a chance did it. This time seams I coped with it by bloating the document not the worst outcome I can do. So yes some of my anti dyslexia training worked just not enough to produce a normal document.

Even worse I missed the important bits. Even that when I read them back to me they were there.

--Really need put from here on up instead ---
Release time is not the factor of quality ever. Ok altering it can trick you into thinking you have improved quality.

Good Quality Controls provides means to keep patches outside the main tree and applying patches to the main tree when they are upto quality.

There are still a lot of projects out without even development tree/s or always insists that everything in the development tree must go into the next release. Direct effect of doing either is longer release times or defective releases.

Longer release time gives the appearance its working. Yes less over all numbers bugs can appear in the final product can look less. Instead of many short lasting bugs ie higher bug numbers in faster release have been replaced with many long lasting bugs.

So the amount of time user is suffering with bugs normally does not change at all if anything longer release cycle makes it worse.

Quality controls are the only thing that can alter the amount of time users are suffering with bugs. Quality controls are all about the bugs never getting to the user in the first place and if bugs get to users getting it fixed as soon as able.
--end--
And yes that is close to what I was reading that mess as. I think I know what doomed it. I got the stupid idea of including examples. Ok normal person not stupid. Person like me downright asking for it.

Ok leave it here for comment first just in case second lot of nightmare in a row. Sorry everyone I try to keep my Dyslexia under control.

Anonymous said...

Oiaohm, something not so relevant to this topic: Have you reached a conclusion with regard to MS' tactic with .net/mono? It appears that MS and de Icaza are pushing mono on the client, effectively leveraging it to neutralize java on the server side. Would I be wrong to say that this is what the MS/Novell deal is all about?