Discussion on bug tracking and management of open source software

Open Source software Bug discussion on tracking and managementNovember 2007
SummaryThis article first introduces the common process of bug management, then analyzes the characteristics of the bug tracking and management system applied in the open source software development process, describes a typical bug life cycle process, and explains the completion of a qualified bug report. The article also briefly introduces the more popular defect tracking and management system Bugzilla, and gives the personal idea. Key Words:Bug management, lifecycle, defect tracking and management systems abstract-This paper introduces a normal bug management process, analyzes characteristics of bugs tracking and management in DEVELOPM ENT of Open source software, describes a classic bug life cycle, and explains how to accomplish an eligible bug report. Also, some popular bug tracking and management systems such as Bugzilla is introduced, following with some personal thoug Hts. Key Words:Bug management, life cycle, bug tracking and management system 1 Problem DescriptionIn the process of software development and maintenance, it is particularly important to carry out quality control and guarantee work effectively. Because of this, software defect tracking and management is an important aspect of implementing quality control and assurance in the process of modern software. Defects (defect or bugs) in software are "by-products" in the software development process. Often, defects can cause a software product to somehow fail to meet the needs of the user [[1]]. The open source organization claims that open source is designed to achieve better quality, greater reliability, greater flexibility, lower costs and the end of predatory vendor confinement [[2]]. As it says, open source software is a spirit of freedom and openness that has ushered in some advocates. However, software defects always exist, how to implement the bug tracking and management of open source software. What is the difference between it and commercial software defect management? What are open source people using for their bug tracking system? With doubt and confusion, I began to explore the issue of open source software bug tracking and management. 2 bug tracking and open source software bug Management 2.1 General process of defect managementSoftware is not perfect, and under normal circumstances, annoying bugs are unlikely to be expected by software engineers. Defect tracking management is an important part of testing, and the purpose of testing is to identify defects in software systems as early as possible, so it is an important part of the test to track and manage defects and ensure that every defect found is handled in a timely manner. No one wants to have too many flaws in their product, but since there is a flaw, it should be tracked and managed. Before we introduce the defect tracking and management of open source software, we need to have a systematic understanding of the general defect management process. Software errors (bugs) are generally found in the testing process, and how to deal with the errors found in the test will directly affect the effectiveness of the test. For bugs found in tests, a clear management process is required. First, the tester submits a new bug to the library, the error status is new, and then the Advanced tester verifies the error, if the acknowledgment is an error, is assigned to the appropriate developer, sets the status to open, and if it is not an error, it is set to the declined State; The developer queries the bug where the status is open, and if it is not an error, the status is declined, and if it is a bug, fix the collocated state to fixed. For a bug that cannot be resolved, leave the text description and keep the bug open, but for the bug that cannot be resolved and postponed, it is not up to the developer to decide, usually through some kind of meeting (jury) to approve. Finally, the tester queries the bug with a fixed status, and then verifies that the bug has been resolved, such as fixing the bug's status to closed, if no resolution is reopen [[4]]. In this process, we can find that it is more demanding for testers, and should not be treated as bugs for problems that might not be wrong. 2.2 Open Source software bug ManagementIn contrast to conventional bug management processes, open source software's defect tracking and management is certainly not beyond it. However, as we have mentioned, the particularity of the open source software development model also puts forward new and stricter process requirements for its bug tracking and management process. In this case, it is necessary to have a more correct understanding of the defect tracking system (bug Tracker) first. Defects include product errors, requirements and design changes, new features or extensions (Feature, enhancement), etc., which exist throughout the software development lifecycle [[5]]. So, what information does a bug Tracker to keep? Bug tracking system in the software development process is often used to record new functional requirements, task logs, patches, etc., as long as there is a clear start and end of the state of things, they and in the process of the transformation and the resulting information should be stored in the system. Compared to the commercial software development process, in the open source software development process, a bug's typical life cycle is this: the problem reporter (may be ignorant of the project) summarizes the problems, gives the appropriate initial description, the information is archived, and then submitted to the system, other users or testers read the bug information, may give further comments, in which case the archiver may be required to clarify some of the issues in the process, and the problem is repeated in other user experiences, and repeated occurrences indicate that the problem does exist, and that this process is an important phase in the life of a bug. Because an unreal bug may be closed or deleted at this stage, the problem or defect is diagnosed, and the cost of resolving it is estimated, and this process may be done by the development member, but it may also be a passionate user; The problem resolution time has a preliminary plan, possibly in one but not necessarily the next version, The problem is resolved, and finally, the problem is resolved, and the related changes should be logged and the issue should be closed. However, the above procedure may stop halfway. So why is a bug going to die in the middle of it? In fact, it can be thought that the bug reporter may be unfamiliar with the project or software products, so that he may submit a wrong problem report. This way, the bug may be turned off quickly. Another factor of change is that the same problem is already documented in the system and may even be solved. In this case, this redundant bug will be removed. Of course, the developer may think that a bug does not exist at all, or that the developer simply changes some places to think that the bug no longer exists, so he may turn off the problem that is not actually solved [[6]]. 2.3Bug ReportTechnical support is considered a terrible job because there are poor bug reports that need to be dealt with [[7]]. We can see that when a problem or defect occurs, the system may be reported by many users and testers, so how to effectively implement the bug tracker. An open source project starts, the bug tracking system also starts to run, it generally runs on the server of the C/S/b architecture. On the client side, it provides one or more user interfaces, such as Web Forms, mail, etc., some bug tracking systems also provide some submission tools to simplify user operations. We first focus on the interface to the client, for example, a tester wants to report a bug, he first enters the bug report interface, but more often, the system always prompts the tester to pay attention to things. In fact, the most important thing before reporting a bug is, of course, finding the bug and trying to find out why. As new Linux novices may be told, try to focus on the current problem and try to find out why [[8]]. A friendly bug reporter can not just be aware of complaining, in the report is randomly described: pop-up annoying window. Such a report will produce ambiguity, so how to submit a qualified bug report. Elisabeth Hendrickson wrote in one of his books: When you write bug reports, remember your listeners, choose a good title, clearly record the steps and explain the impact of the error; Your bug report will be better because of the extra effort you spend on it. And there are more errors to be repaired, and eventually we will achieve the results we expect-making the bug fix before hurting the user [[9]]. The famous open source software quality control and assurance platform Mozilla provides a good bug report that should contain the following information: Software version serial number, operating environment, error site information, debugging and warning information, etc. [[10]]. In practice, the defect tracking system is necessary to provide the appropriate interface to the user. 3 Typical bug tracker introductionOpen source software field, there are many bug tracker, more famous have Bugzilla, Gnats, Buggit, Mantis, Dbts and so on. These defect tracking and management systems provide a good means of control for open source software management. Software development needs the existence of bug Tracker, open source software development is more inseparable from them. Mr. Zhenfei Liu, the initiator of open source bug Tracker Bugfree, who worked for Microsoft, said: "All of the tools I admire most are the bug management system RAID (now called Product Studio). The value of RAID is that it closely tracks the actual bug status of the current product, making it very effective for members of the project team to coordinate their work [[11]]. Similarly, open source software does not have the appropriate bug management software support, I am afraid it is difficult to develop a good product. Below we can understand some of the mainstream systems in this area, Mozilla provides Buzilla is a product defect recording and tracking tool, it can create a complete bug tracking system for you, including reporting bugs, querying bug records and generating reports, processing resolution, The administrator system initializes and sets four sections. It has the following characteristics: Web-based, easy to install, easy to run, management security, to facilitate the clear transmission of defects, flexible system, strong configurable ability, support automatic email [[12]. In contrast, Mantis is the php/mysql/web-based defect tracking system, which has the advantages of individual customizable email notifications, multi-project support, and multi-lingual features []. In addition, online bug tracking and management systems such as Trackstudio, Bugols provide an excellent user interface. In particular, Bugols's manifesto on its homepage makes it ideal for every programmer to publish and maintain their own programs with the mission of building the world's most convenient, easy-to-use, and user-friendly online bug management tools through superb technology []. However, most bug tracking systems seem to focus too much on how to manage bugs, ignoring the effective integration with automated quality assessment tools. On the other hand, many researchers try to design a new project quality assessment tool using the source code of the Open source project and the usability of the test data [[15]]. Maybe they can do more work on bug tracking and management system design. 4 ConclusionAfter introducing the knowledge of bug tracking and management, this paper analyzes the tracking and defect management of open source software in particular. The study found that how to submit a friendly bug report to the bug tracker is very important to solve the problem in a timely, effective and correct manner. However, most web-based bug tracker provide a detailed blank bug list for users to fill out, although this approach is convenient for the system to effectively accept and handle bugs, but ignores the rich and complicated forms that exceed the limits that the bug submitter can withstand. Of course, these systems take a few drop-down list selections, but too many users must operate without being satisfied. In addition, the interface of these systems is not beautiful enough to imagine a non-professional to report a bug, the unfriendly interface may cause him to give up reporting a potentially fatal bug. The solution is to choose a balance between the required information and the additional information, while providing a clean interface. Another problem is that most bug tracker will reject repeated commits, but the type of bug, report time, and reporting frequency are important evaluation parameters [[16]]. This way, if the system blindly refused to commit the duplicate bug, I am afraid to count the frequency of a bug will also be a problem. In practice, most bug tracker have the ability to filter bug reports to resist duplicate submissions or existing problem reports, and some systems can fully accept e-mail submissions or work with mailing lists; The filtering mechanism is actually something that requires skill and excellent algorithm. Just imagine a problem. The author submits a report on the issue that is inconsistent with the problem description in the report, and what will be the result. This could be an important report, but the reporter made a mistake on a momentary negligence, but the system rejected it as an existing simple mistake. The problem is that the next version of the project may fail because of that bug, and the consequences may be severe. In fact, the question to be pointed out here is how to effectively and accurately filter bug reports. In fact, there are some search and match technology involved, the system not only to check the bug subject, but also to check its internal information. How to implement it efficiently. This is a confusing and intimate topic. Perhaps we can expect the progress of machine learning theory and application, when the system is quite intelligent, it may be possible to quickly catch a possible bug, and automatically modify the possible errors, so that a bug report is complete, consistent, accurate. In that case, a bug tracker will run more efficiently and may play an important role in the progress of open source software. AcknowledgementsIn the course of the study, our team members had a good communication and exchange of views on some issues, forming a good team atmosphere. At the same time thanks to the teacher to give guidance and help. References
[1]      Liu Yin. << software defect Management >&gt,  2005. [[2]] http://www.opensource.org/[[3]] close the river. << also talk about defect tracking management >&gt. On http://www.testage.net/TestTech/BugM/200601/120.htm. 2006. [[4]] Tii Qiliang. <<bug management of the general process >>. Http://www.51testing.com/html/34/1275.html, 2006. [[5]] Cai Yan. << use open source software Mantis to implement defect tracking successful practice >&gt. Http://www-128.ibm.com/developerworks/cn/linux/software_engineering/l-mantis/index.html, 2003. [[6]] Karl Fogel. Producing Open Source software:bug tracker.o ' reilly,2005. [[7]]http://www.cndw.com/tech/php/2006041847238.asp [[8]] found bug. On Http://kernelnewbies.org/FoundBug [[9]] Elisabeth hendrickso, translated. Writing effective Bug Reports. On Http://www.51testing.com/html/34/67.html, 2005. [[[]] Chrisyeh. How to write a good bug report.http://www.mozilla.org/bugs/bug-reporting.html [[11]] Zhenfei Liu. Experience and practice in bug management. On http://bugfree.newsky.cn/zhenfei/Document/BugFree.htm. [[12]] Xu Yanji. The test Trace tool Bugzilla introduced. On http://www.csai.cn. [ [13]] with [5]. [[]] bugols. On http://www.bugols.com. [[[]] Georgios Gousios,vassilios Karakoidas, Konstantinos Stroggylos, Panagiotis Louridas, Vasileios Vlachos, and Diomid Is Spinellis. Software quality assessment of Open Source software. New Technologies Publications, 2007. [[+]] Adriaan de Groot1, Sebastian k¨ugler1, Paul J. Adams2, and Giorgos Gousios3. Call for Quality:open Source Software quality observation. The Second international Conference on Open Source Systems, 2006.   NOTE: Refer to this article to indicate the source of the relevant ideas