bmlk - Bernds memory leaks

Strong Module Ownership

If you thought that MNG is the poster case for ownership, try dilbert

Wordle

Its cool how wordle

puts in single picture what drives you internally.

Why the Bugathon is OK, but does not solve the real problem

The numbers

Gerv did revive the Bugathon. So I went trough the bugs at layout tables to see how many bugs really need a testcase.

I did this in several steps.

1. search for all bugs that do not contain the keyword testcase but do have a attachment which is named testcase, and assign the testcase keyword.


2. search for all remaining bugs that do not contain the keyword testcase but do have a attachment which is of type text/html, decide if they are real testcases and assign the keyword


3. Go through the remaining bugs, that do not contain the keyword testcase. During this step a lot of old unconfirmed showed up that have been WorksForMe. I know from previous experience that WFM's can be for ever not closed, so I closed them aggressively and asked to reopen with a clear explanation whats going on.


4. I found 6 bugs where a testcase would be beneficial. There are 50 bugs that do not need a testcase but I did not mark them.
   
5. So out of 450 bugs only 6 bugs need a testcase.
   

As a result we have now 400 table bugs with a testcase that are also marked by the keyword testcase.

In the last year 180 bugs got marked fixed in the layout-tables component. 36 of them have been assigned to nobody@mozilla.org and are fixed by other bugs.

In the same time period 136 bugs have been marked as WFM. This means we have roughly for every really fixed bug one WFM.

This hints that one needs to deal with the WFM category.

The WFM's

A triaged bug that ends purely as a WFM is a waste of resources. We waste

• the reporters time,


• the time spent on triaging and


• the time spent on creating a testcase.

So the minimum requirement is that the testcase ends as testcase in our tree.

Yes, wfm too. Could you please flag the bugs you resolve with in-testsuite?
when there is testcase attached to the bug? I think it would be valuable to
add these as reftests because they are often edge cases and it makes sure we
have good code coverage in the tests. (Or even better, make a reftest and
just check it in ;-) ) Mats Palmgren

Reftests

Converting usual teastcases to reftests requires knowledge and time. Its far more efficient to create a reftest when the bug is still present then to create one once the bug got WFM. Currently this is mainly done by the developers and this is where we really waste the most expensive resource that we have.

It would already help tremendously if a testcase would contain the bug and the expected rendering so that files needs only be split. This can be done by nearly everyone who is able to create a testcase.

Such a testcase has the obvious benefit that it can be easily converted into a reftest and it has also the advantage that triaging if the bug is still present becomes very efficient.

Continuous triage

I have seen a lot of bugs that had testcases that linger for years in our database. So if we really care about developer time then it would be far more efficient
to triage the existing bugs properly, to verify that they still exist and to make them compatible to the automated test frameworks rather than trying to get the latest bug out of firefox:general.
This triage requires experience that one only gets trough focus. This means experienced QA folks should take responsibility for fixed components and improve the bug quality in this components in a way that results in checkins into the tree.

Just by looking at the numbers of open bugs one should ask himself is this testcase self explaining in two, three or four years.
Can it be easily judged, that it is still an open bug. And this late triaging is the point where simply reviving the old Bugathon is not good enough. It is typically very difficult to see if a testcases that is WFM is really WFM.

Summary

The question for me looks like do we care for 6 or for 400 bugs. I would vote for the 400. And having on those 400 bugs reftests would help much more than the testcases on the 6 bugs

test cases required

Rob highlights a important question, when test cases as a requirement are too much for a starting contributor. This is different for UI compared to layout. In layout most people that I know came via the test case reduction (bugathon). So they are used to it. In UI this is different. I would propose to make the test case requirement only for people with CVS write permission. If those refuse they should not have the write permission and beginners will not be tortured.

Zarro Boogs found.

3 years ago I posted my private Mozilla road map: "drive the number of crash bugs in the layout table component down to zero".

Today is the first day that I am aware off without a known table crash bug in the Mozilla code base. That probably covers all the 8 years that I am around this stuff.

I am very proud of it and its a feeling of relieve.

The big thanks go to Boris, Jesse, Martijn and Mats.

Code Review Avoiding Patches

I am a big believer in code review , it is what makes Mozilla strong. I am very suspicious when people try to avoid review. Regardless what the excuse is at the end usually the code has errors that proper review would easily have been resolved before check in. This was my main concern with the initial Phoenix Firefox development. Typically I am not a big fan of Mozilla corporate decisions as they are frequently done behind the scenes. I blame this to the bad Carma of Mountain View which is inherited from the old Netscape days.

However there is one thing where I stand 100% behind Mozilla and that is the trademark policy. If you say a thing is a Firefox than it has to be a Firefox and nothing else. If Debian makes modifications and then refuses to get them properly reviewed by people who understand the code the output is predictable: lower quality than the original code base. Mozilla says this lower quality product shall not spoil our name and is IMHO right to do so.

So lets have a walk what that means:
I installed a while ago Ubuntu on my brothers machine to get rid of spyware etc. At this time Mozilla 1.7 was shipped and I was pretty unhappy with the Firefox development cycle (see above). I launched the application and found the layout debugger?!? Ubuntu does not use a typical bugzilla so i was pretty lost but anyway I filed the corresponding bug . So what was the root cause of this bug. Somebody at Debian spoiled it till today ( search for extensions=all or follow bug 393859). Nobody at Mozilla, who has at least a minimal build understanding will approve such a patch. And I think that it would be good for Debian too as it would not ship applications with a broken user interface and dubious security.

This would certainly limit the freedom of Debian to modify the source. But why should users of Debian and many Ubuntu users suffer from bad preventable code changes?

So to whom it applies: if you need help porting a patch that I have written to Debian because you follow the very bad idea of maintaining the Firefox 1.0.x series (its a security problem in my eyes) file a patch in bugzilla and ask me for review.

UPDATE: I just came across the blog of the Firefox maintainer:

• Changes to disable application upgrade (we want that to happen through apt-get) and change some other default preferences,
  
• Changes to fix “make distclean” so that it really cleans the build directory,
  
• Change not to build the “mangle” utility,
  
• Change not to call netstat to generate entropy, which is useless on linux,
  
• Changes to work around bugs with the hidden visibility pragma on gcc,
  
• Changes to make the pango backend actually build correctly,
  

And you don't want that people who wrote code review this???? Has the pango backend even a tinderbox? If mozilla has not shipped the test builds before how can that back end have the proper testing?

Private Bugzilla rules

1. Assign every regression that my checkins have caused to me.


2. Assign every crash in table code to me.
   

   
   

   crash in table code

   
   

   Among the top three functions is a function from layout/tables, or it crashes inside nsCSSFrameConstructor.cpp and the function is table related

   
   

   
   


3. Put me on CC if something asserts in table code.
   
4. Put me on CC if something crashes and a table display type is involved.
   
5. Put me on CC if you need advice how to fix a bug and think I should know it.
   
6. Put me on CC if you think that I can fix it with a few lines, this rule only applies to Boris, David and Robert.
   
7. For all other cases I read daily bugs that changed in the layout tables component.