coder . cl

As software developers we reach bugs many times. In Open Standards, bug reports reach a common point: “every bug report has a reasonable description and have attached the proper backtrace or debug examples to reproduce the target bug“. Writing a good bug report implies a good written problem description. Many FOSS software have embeded an automatic bug report generator, but also many developers are helping with complex bug reports that aren’t handled by these systems.

Mandatory development tools in any project are bug tracking systems and version control systems. Commercial side of software developemnt knows bug tracking systems as ticket systems, but don’t have another meaning. Who says that isn’t making any mistake on software development is wrong. We have clear examples on huge companies with known bugs issues.

The Dark Side

From the Microsoft NON-WORKING Knewledege Base we get a message like this.

As a result, Windows Explorer does not allow you to view or change the Read-only or System attributes of folders. When a folder has the Read-Only attribute set it causes Explorer to request the Desktop.ini of that folder to see if any special folder settings need to be set. It has been seen where if a network share that has a large amount of folders set to Read-only, it can cause Explorer to take longer then what is expected to render the contents of that share while it waits on the retrieval of the Desktop.ini files.

Obviously, this message tell us about a known bug — if you work with software that isn’t enable to write forcibly the files, you will not be able to save your work — but hidding by commercial targets. Seems like Micro$osft is making perfect software, you can’t report a bug anywhere. The worst philosphy on software developemnt. Also, the knowledge base is closed to the users — nobody can contribute with it.

Also, if I try to report a bug on Micro$oft products, and I search where to submit the problem, I get poor results. I ask if Micro$osft can handle an Open Source Model bug reporting system, how many errors would be reported by the users, remembering that the common Windows user have no knowledge on how to submit a probem report because they think that everything with their systems is OK.

The Force

In FOSS software, we get elegant ways to report bugs. We have have the direct feedback from the developers. But we must do the proper bug report.

Known ways to report a bug is using gdb backtraces and bug unit testing. A well betatester know how to compile the code and store the debugging symbols of the tested software — that’s the advanced way, a non-interrumping-performance way to get the debugging version — and the other way is pytting directly the debugging symbols in the software:

# the same flags applies to CPPFLAGS or CXXFLAGS
# configuring with debugging flags
env CFLAGS="-g3" ./configure --the-configure-options

# configuring with debugging and profiling flags
env CFLAGS="-g3" ./configure --the-configure-options

# do "man env" if you don't know env(1)

The, we begin our software testing, if we get a core dump, we can get the origin of the problem. After getting core dump images, we must set out core limit with ulimit built-in command — this command is common to the most shells available.

# start our backtrace
gdb /path/to/our/program /path/to/the/core.image

# then, inside gdb we get the backtrace by using the backtrace
(gdb) backtrace

A common way to get backtraces and report bugs to the FOSS developers. Then, we reach the Bug Tracking Systems and Issue Tracking Systems. The intersting part of this, is that the language used to report bugs is almost right, the common FOSS user knows how to describe the bug, from what was doing the user to problem it self — when the user have a well knowledege on what is reporing.

Keeping the software controlled is a hard task. Now we have a lot of tools on Version Control, Issue Tracking and Bug Reporting. Also the mailing lists helps a lot — the communication way of most FOSS projects — on solving problems as teams.

Every FOSS project has a bug report writing guidelines, the language must be clear and consistent, also can have attached the propper patch. The real nice thing of this: if the bug report is clear and points to the real problem, you quickly will get feedback from the developers — depending on how seriously is it. On commercial software, is hard to get a core image and then report a bug correctly. Some Micro$oft products are sending these images — recently added to their products — but you need to mount a development environment before.

I know people aged from with ages between 14 to 16 years old writing good PR’s or bug reports, I belive that they will be good FOSS software writters too, someday. They know the FOSS rules, such as RTFM. The FOSS community appears to be more motivated and dedicated to the software development than closed software developers. Every Windows user, aged from 14 to 16 years that I know, is always thinking on games, loosing time, then are asking about how to remove certaing virus from his computer or how to overclock his machine. I’ve seen some of these guys saying I will be a computer engineer, but not worried on what is learning really. How many hours doing nothing?. I disagree on games for younglins, I agree only if they have trained correctly xD.