DOCSLIB.ORG

Scmbug: Policy-Based Integration of Software Configuration

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Scmbug: Policy-based Integration of Software Configuration Management with Bug-tracking Kristis Makris Kyung Dong Ryu Department of Computer Science IBM T.J. Watson Research Center and Engineering 1101 Kitchawan Rd Arizona State University Yorktown Heights, NY 10598 Tempe, AZ, 85287 [email protected] [email protected] Abstract and enhancement requests. Those who do not use a bug-tracking system tend to rely on shared lists, Software configuration management(SCM) and email, spreadsheets and/or Post-It notes to moni- bug-tracking are key components of a successful tor the status of defects. This procedure is usually software engineering project. Existing systems error-prone and tends to cause those bugs judged integrating the two have failed to meet the needs least significant by developers to be dropped or of the ASU scalable computing lab, powered by ignored[10]. open-source software. An improved solution to By examining a log of software changes from the integration problem, designed to accomodate an SCM tool, it is uncertain why the changes oc- both free and commercial systems alike, is pre- curred. By examining a defect report, it is un- sented. certain what changed in software in response to Scmbug offers a policy-based mechanism of the defect. Integration of SCM with bug-tracking capturing and handling integration of SCM ties the reason why a feature/defect was devel- events, such as committing software change- oped/fixed with what software changes occurred sets and labeling software releases, with a in the SCM system to accomplish this. Marry- bug-tracking system. Synchronous verification ing the SCM and bug-tracking systems improves checks and the flexibilty to match multiple devel- the traceability of software changesets, quality of opment models separate this approach from re- documentation in defect reports, and quality of lated work. We address design limitations of ex- release documents. isting integration efforts, suggest improvements SCM[11, 9, 18, 6, 5, 7, 3] and defect- in SCM and bug-tracking systems required to tracking[2, 4, 1] systems are widely popular and achieve a scalable solution, and document our in deployment. Commercial systems implement early integration experiences. a mostly inflexible integration of the two, and free systems lack a variety of important verification 1 Introduction guarantees. None of the existing systems met the integration demands of the ASU scalable com- SCM is key[17] in maintaining quality in soft- puting lab. At a minimum, an integration system ware engineering. SCM systems, or even simple should provide: version control systems, guarantee that a record • Integration of common denominator SCM of all changes and enhancements to software is events, such as committing changesets and maintained. When bugs creep in software, a trace labeling releases. When a changeset is of how changes occurred is available, simplify- committed, the accompanying log message ing the process of identifying regression points should be inserted in the bug-tracker. The and correcting defects. list of affected files, and the older/newer Paired with SCM, bug-tracking is another key version numbers of each file, should be re- in engineering quality software. Defect-tracking flected in the bug report. When a release systems guarantee that nothing gets swept under is labeled, the release version should be in- the carpet; they provide a method of creating, serted in the bug-tracker. storing, arranging and processing defect reports • Synchronous verification checks of SCM USENIX Association FREENIX Track: 2005 USENIX Annual Technical Conference 11 actions against the bug-tracker. If a devel- changes. Additionally, integration with other oper attempts to commit a changeset against bug-tracking systems requires implementing a an invalid product or bug id, the commit ac- communication interface with the target bug- tivity should fail, and the developer should tracker. Finally, the integration is unsuitable for be informed immediately. deployment across the public Internet, for rea- • Policy-based configuration. The integration sons explained in Section 5.1. system should be able to match the develop- In the free software arena, the most fre- ment model followed by an organization by quently attempted integration involves CVS[11], tuning run-time parameters. the dominant open-source network transparent • Secure deployment of the integration over version control system, with Bugzilla, a free de- the public Internet. fect tracking software that tracks millions of bugs • An interface to integrate any SCM system and issues for hundreds of organizations around with any bug-tracking system, overcoming the world. Steve McIntyre’s website[21] docu- limitations of the involved systems where ments an approach using trigger scripts to email possible. CVS’s actions to an account (Bugzilla Email • A mechanism to produce a Version Descrip- Gateway) configured to parse the email and pro- tion Document (VDD) detailing the defects cess it accordingly. This approach is not syn- corrected, and the changesets involved in chronous. If a user accidentally commits against fixing a defect, between two releases of a the wrong bug number, or a bug against which he software. is not the owner, the SCM system will proceed Scmbug is designed to meet these require- with the commit action regardless. The user will ments. It is implemented in Perl, an excellent, not be given the option to correct her actions. Ad- cross-platform, glue programming language, for ditionally, if the email gateway is not active, the UNIX-like systems, such as Linux, AIX, and So- developer will not be immediately aware that in- laris. It currently supports integration of CVS and tegration failed. Subversion with Bugzilla. The somewhat dated CVSZilla[15] project also integrates SCM events produced by CVS with The rest of this paper is structured as follows. Bugzilla 2.10. It does not support integration of Section 2 outlines the limitations of existing sys- events produced by any SCM system in a generic tems that prompted our solution. The system de- way. Moreover, it modifies the Bugzilla schema, sign is presented in Section 3, and a short exam- and as a result does not work with current ver- ple in Section 4. The system’s components are sions of Bugzilla, such as 2.18. Finally, this in- analyzed in Sections 5, 6, and 7. Section 8 brings tegration is unsuitable for deployment across the to light the improved quality of release documen- public Internet. tation enabled by this system. Early experiences John C. Quillan was first to conceive and im- using Scmbug are documented in Section 9, and plement synchronous verification checks and a insight to future work is given in Section 10. Fi- VDD generator, in work that was never pub- nally, Section 11 concludes this paper. licly released. He integrated CVS with Bugzilla, but his design did not support any SCM sys- 2 Related Work tem with any bug-tracking system, or deployment over the public Internet. Scmbug incorporates In the realm of commercial products, Perforce[7] these features, and proposes a more flexible de- and ClearCase/ClearQuest[3] only offer integra- sign that can accommodate both free and com- tion of their own SCM and bug-tracking sys- mercial SCM and bug-tracking systems. tems, in a proprietary way. They do not read- ily support integration with free SCM systems, 3 System Architecture such as CVS[11], Subversion[9], and Arch[18] or free bug-tracking systems such as Bugzilla[2] Scmbug is a client/server system. As shown in MantisBT[4], and AntHill[1]. Work enabling Figure 1, it consists of a set of SCM system hooks integration of Perforce with Bugzilla 2.0-16 is that capture standard SCM events and a generic available[8], but the integration API lacks an ab- glue mechanism of handling these events on stract bug-tracker interface, and requires mod- the machine hosting an SCM repository. These ifications released by the Perforce integration events are translated into integration requests and team every time the Bugzilla database schema transported to a server daemon. The daemon em- 12 FREENIX Track: 2005 USENIX Annual Technical Conference USENIX Association loginfo, verifymsg, Bugzilla API: taginfo hooks Scmbug globals.pl CVS CGI.pm Bugzilla Integration Glue Daemon activity.pl TCP port 3872 native Subversion Mantis API Mantis pre−commit, post−commit hooks Figure 1: Scmbug system architecture diagram ploys a generic mechanism of handling these re- Figure 3 presents the log comment stored in quests and contains functionality that can process CVS, produced in a more readable Changelog these requests per bug-tracking system. format using the cvs2cl tool, in response to The integration glue follows a common in- this changeset. This entry clearly details what terface of handling SCM events, and groups changed: a global variable is introduced to hold the logic driving the behavior of the integra- the name of the network device. However, it does tion. SCM-specific implementation idiosynchra- not explain why this change was required. Why cies, such as parameter decoding from SCM must a global variable be used instead of a hard- hooks, are isolated in separate modules. The ab- coded value? To identify the reason why these straction of an integration glue is what permits files were modified one must consult the bug- any SCM system to be integrated using Scmbug. tracking system. This log entry refers the reader The integration functionality is always executed to bug id 417. on the machine hosting the SCM repository. Figure 4 captures the comment entered in Respectively, the integration daemon imple- Bugzilla in response to the changeset. The origi- ments a common interface of accepting and pro- nal SCM log message is included in the bug com- cessing integration requests. Bugtracker-specific ments. The integration also generates a list of af- functionality, such as reading metadata and up- fected files, matched with the older/newer version dating bug comments, is implemented in separate numbers of each file, and appends it to the log modules.
Recommended publications
  • Pragmatic Version Control Using Subversion

    Pragmatic Version Control Using Subversion

    What readers are saying about Pragmatic Version Control using Subversion I expected a lot, but you surprised me with even more. Hav- ing used CVS for years I hesitated to try Subversion until now, although I knew it would solve many of the shortcom- ings of CVS. After reading your book, my excuses to stay with CVS disappeared. Oh, and coming from the Pragmatic Bookshelf this book is fun to read too. Thanks Mike. Steffen Gemkow Managing Director, ObjectFab GmbH I’m a long-time user of CVS and I’ve been skeptical of Sub- version, wondering if it would ever be “ready for prime time.” Until now. Thanks to Mike Mason for writing a clear, con- cise, gentle introduction to this new tool. After reading this book, I’m actually excited about the possibilities for version control that Subversion brings to the table. David Rupp Senior Software Engineer, Great-West Life & Annuity This was exactly the Subversion book I was waiting for. As a long-time Perforce and CVS user and administrator, and in my role as an agile tools coach, I wanted a compact book that told me just what I needed to know. This is it. Within a couple of hours I was up and running against remote Subversion servers, and setting up my own local servers too. Mike uses a lot of command-line examples to guide the reader, and as a Windows user I was worried at first. My fears were unfounded though—Mike’s examples were so clear that I think I’ll stick to using the command line from now on! I thoroughly recommend this book to anyone getting started using or administering Subversion.
  • Debian Developer's Reference Version 12.0, Released on 2021-09-01

    Debian Developer's Reference Version 12.0, Released on 2021-09-01

    Debian Developer’s Reference Release 12.0 Developer’s Reference Team 2021-09-01 CONTENTS 1 Scope of This Document 3 2 Applying to Become a Member5 2.1 Getting started..............................................5 2.2 Debian mentors and sponsors......................................6 2.3 Registering as a Debian member.....................................6 3 Debian Developer's Duties 9 3.1 Package Maintainer's Duties.......................................9 3.1.1 Work towards the next stable release............................9 3.1.2 Maintain packages in stable .................................9 3.1.3 Manage release-critical bugs.................................. 10 3.1.4 Coordination with upstream developers............................ 10 3.2 Administrative Duties.......................................... 10 3.2.1 Maintaining your Debian information............................. 11 3.2.2 Maintaining your public key.................................. 11 3.2.3 Voting.............................................. 11 3.2.4 Going on vacation gracefully.................................. 12 3.2.5 Retiring............................................. 12 3.2.6 Returning after retirement................................... 13 4 Resources for Debian Members 15 4.1 Mailing lists............................................... 15 4.1.1 Basic rules for use....................................... 15 4.1.2 Core development mailing lists................................. 15 4.1.3 Special lists........................................... 16 4.1.4 Requesting new
  • Free Software Needs Free Tools

    Free Software Needs Free Tools

    Free Software Needs Free Tools Benjamin Mako Hill [email protected] June 6, 2010 Over the last decade, free software developers have been repeatedly tempted by devel- opment tools that offer the ability to build free software more efficiently or powerfully. The only cost, we are told, is that the tools themselves are nonfree or run as network services with code we cannot see, copy, or run ourselves. In their decisions to use these tools and services – services such as BitKeeper, SourceForge, Google Code and GitHub – free software developers have made “ends-justify-the-means” decisions that trade away the freedom of both their developer communities and their users. These decisions to embrace nonfree and private development tools undermine our credibility in advocating for soft- ware freedom and compromise our freedom, and that of our users, in ways that we should reject. In 2002, Linus Torvalds announced that the kernel Linux would move to the “Bit- Keeper” distributed version control system (DVCS). While the decision generated much alarm and debate, BitKeeper allowed kernel developers to work in a distributed fashion in a way that, at the time, was unsupported by free software tools – some Linux developers decided that benefits were worth the trade-off in developers’ freedom. Three years later the skeptics were vindicated when BitKeeper’s owner, Larry McVoy, revoked several core kernel developers’ gratis licenses to BitKeeper after Andrew Tridgell attempted to write a free replacement for BitKeeper. Kernel developers were forced to write their own free software replacement: the project now known as Git. Of course, free software’s relationships to nonfree development tools is much larger than BitKeeper.
  • Everything You Need to Know About Openjdk's Move to Git and Github

    Everything You Need to Know About Openjdk's Move to Git and Github

    Menu Topics Archives Downloads Subscribe Everything you need to know JAVA 17 about OpenJDK’s move to Git and GitHub Everything you need to know Blame or thank BitKeeper about OpenJDK’s move to Git Why not Mercurial? and GitHub Why Git? Why GitHub? Why the move, and why now? The move from Mercurial to Git Getting the source code and provided an opportunity to consolidate building the OpenJDK the source code repositories. Conclusion by Ian Darwin Dig deeper May 14, 2021 Download a PDF of this article Have you ever built your own Java Development Kit from source? Most end users of the JDK will not need to build their own JDK from the Oracle source code. I’ve needed to do that only a few times when I was running on the OpenBSD UNIX-like system, which is not one of the three supported platforms. Sure, you might want to build your own JDK to try out a new feature that you think should be added to Java. You might choose to build from source to be sure you are running a more trustworthy binary. Having the complete source code readily available, and now in a more commonly used download format, means it is easier than ever to build your own JDK. Yes, it’s a better-documented, easily configured process than in the past. But it’s still a bit confusing. The source code for the OpenJDK recently moved from the Mercurial version control system (VCS) to the Git VCS and the GitHub repository system, and that’s probably a good thing.
  • Code Review Guide

    Code Review Guide

    CODE REVIEW GUIDE 2.0 RELEASE Project leaders: Larry Conklin and Gary Robinson Creative Commons (CC) Attribution Free Version at: https://www.owasp.org 1 F I 1 Forward - Eoin Keary Introduction How to use the Code Review Guide 7 8 10 2 Secure Code Review 11 Framework Specific Configuration: Jetty 16 2.1 Why does code have vulnerabilities? 12 Framework Specific Configuration: JBoss AS 17 2.2 What is secure code review? 13 Framework Specific Configuration: Oracle WebLogic 18 2.3 What is the difference between code review and secure code review? 13 Programmatic Configuration: JEE 18 2.4 Determining the scale of a secure source code review? 14 Microsoft IIS 20 2.5 We can’t hack ourselves secure 15 Framework Specific Configuration: Microsoft IIS 40 2.6 Coupling source code review and penetration testing 19 Programmatic Configuration: Microsoft IIS 43 2.7 Implicit advantages of code review to development practices 20 2.8 Technical aspects of secure code review 21 2.9 Code reviews and regulatory compliance 22 5 A1 3 Injection 51 Injection 52 Blind SQL Injection 53 Methodology 25 Parameterized SQL Queries 53 3.1 Factors to Consider when Developing a Code Review Process 25 Safe String Concatenation? 53 3.2 Integrating Code Reviews in the S-SDLC 26 Using Flexible Parameterized Statements 54 3.3 When to Code Review 27 PHP SQL Injection 55 3.4 Security Code Review for Agile and Waterfall Development 28 JAVA SQL Injection 56 3.5 A Risk Based Approach to Code Review 29 .NET Sql Injection 56 3.6 Code Review Preparation 31 Parameter collections 57 3.7 Code Review Discovery and Gathering the Information 32 3.8 Static Code Analysis 35 3.9 Application Threat Modeling 39 4.3.2.
  • Estudos Preliminares

    Estudos Preliminares

    IGOR BESSA MENEZE PODER JUDICIÁRIO S JOSE MARIO VIANA JUSTIÇA DO TRABALHO BARBOSA JUNIOR LENIVIA TRIBUNAL REGIONAL DO TRABALHO DA 7ª REGIÃO DE CASTRO E SILVA MENDES FRANCISC O JONATHAN SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO REBOUCAS MAIA Estudos Preliminares Contratação de Suporte Técnico, incluindo atualizações evolutivas e corretivas, para a ferramenta Atlassian Jira e Plugins eazyBI Reports and Charts e Git Integration. Estudos Preliminares - Contratação de Suporte Técnico, incluindo atualizações evolutivas e corretivas, para a ferramenta Atlassian Jira e Plugins eazyBI Reports and Charts e Git Integration. 1 PODER JUDICIÁRIO JUSTIÇA DO TRABALHO TRIBUNAL REGIONAL DO TRABALHO DA 7ª REGIÃO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO Sumário ANÁLISE DE VIABILIDADE DA CONTRATAÇÃO (Art.14) 4 Contextualização 4 Definição e Especificação dos Requisitos da Demanda (Art. 14, I) 5 Requisitos de Negócio 5 Requisitos Técnicos 6 Requisitos Temporais 6 Soluções Disponíveis no Mercado de TIC (Art. 14, I, a) 7 Contratações Públicas Similares (Art. 14, I, b) 10 Outras Soluções Disponíveis (Art. 14, II, a) 11 Portal do Software Público Brasileiro (Art. 14, II, b) 11 Alternativa no Mercado de TIC (Art. 14, II, c) 12 Modelo Nacional de Interoperabilidade – MNI (Art. 14, II, d) 12 Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil (Art. 14, II, e) 12 Modelo de Requisitos Moreq-Jus (Art. 14, II, f) 12 Análise Comparativa dos Custos das Soluções (Art. 14, III) 12 Escolha e Justificativa da Solução (Art. 14, IV) 15 Descrição da Solução (Art. 14, IV,a) 21 Alinhamento da Solução (Art. 14, IV, b) 22 Benefícios Esperados (Art. 14, IV, c) 22 Relação entre a Demanda Prevista e a Contratada (Art.
  • Master Thesis Innovation Dynamics in Open Source Software

    Master Thesis Innovation Dynamics in Open Source Software

    Master thesis Innovation dynamics in open source software Author: Name: Remco Bloemen Student number: 0109150 Email: [email protected] Telephone: +316 11 88 66 71 Supervisors and advisors: Name: prof. dr. Stefan Kuhlmann Email: [email protected] Telephone: +31 53 489 3353 Office: Ravelijn RA 4410 (STEPS) Name: dr. Chintan Amrit Email: [email protected] Telephone: +31 53 489 4064 Office: Ravelijn RA 3410 (IEBIS) Name: dr. Gonzalo Ord´o~nez{Matamoros Email: [email protected] Telephone: +31 53 489 3348 Office: Ravelijn RA 4333 (STEPS) 1 Abstract Open source software development is a major driver of software innovation, yet it has thus far received little attention from innovation research. One of the reasons is that conventional methods such as survey based studies or patent co-citation analysis do not work in the open source communities. In this thesis it will be shown that open source development is very accessible to study, due to its open nature, but it requires special tools. In particular, this thesis introduces the method of dependency graph analysis to study open source software devel- opment on the grandest scale. A proof of concept application of this method is done and has delivered many significant and interesting results. Contents 1 Open source software 6 1.1 The open source licenses . 8 1.2 Commercial involvement in open source . 9 1.3 Opens source development . 10 1.4 The intellectual property debates . 12 1.4.1 The software patent debate . 13 1.4.2 The open source blind spot . 15 1.5 Litterature search on network analysis in software development .
  • Name Synopsis Description Options

    Name Synopsis Description Options

    reportbug(1) General Commands Manual reportbug(1) NAME reportbug − reports a bug to a debbugs server SYNOPSIS reportbug [options] <package | pseudo-package | absolute-pathname> DESCRIPTION reportbug is primarily designed to report bugs in the Debian distribution; by default, it creates an email to the Debian bug tracking system at [email protected] with information about the bug you’ve found, and makes a carbon copyofthe report for you as well. Using the −−bts option, you can also report bugs to other servers that use the Debian bug tracking system, debbugs. Youmay specify either a package name or a filename; if you use a filename, it must either be an absolute filename (so beginning with a /)orifyou want reportbug to search the system for a filename, see the −−filename and −−path options below. Ifinstalled, also dlocate is used to identify the filename location and thus the package containing it. Youcan also specify a pseudo-package;these are used in the Debian bug tracking system to track issues that are not related to one specific package. Run reportbug without anyarguments, then enter other at the package prompt, to see a list of the most commonly-used pseudo-packages. OPTIONS The program follows the usual GNU command line syntax, with long options starting with twodashes (‘−−’). A summary of options are included below. −h, −−help Showsummary of options. −−version Showthe version of reportbug and exit. −A FILENAME, −−attach=FILENAME Attach a file to the bug report; both text and binary files are acceptable; this option can be specified multiple times to attach several files.
  • Snapshots of Open Source Project Management Software

    Snapshots of Open Source Project Management Software

    International Journal of Economics, Commerce and Management United Kingdom ISSN 2348 0386 Vol. VIII, Issue 10, Oct 2020 http://ijecm.co.uk/ SNAPSHOTS OF OPEN SOURCE PROJECT MANAGEMENT SOFTWARE Balaji Janamanchi Associate Professor of Management Division of International Business and Technology Studies A.R. Sanchez Jr. School of Business, Texas A & M International University Laredo, Texas, United States of America [email protected] Abstract This study attempts to present snapshots of the features and usefulness of Open Source Software (OSS) for Project Management (PM). The objectives include understanding the PM- specific features such as budgeting project planning, project tracking, time tracking, collaboration, task management, resource management or portfolio management, file sharing and reporting, as well as OSS features viz., license type, programming language, OS version available, review and rating in impacting the number of downloads, and other such usage metrics. This study seeks to understand the availability and accessibility of Open Source Project Management software on the well-known large repository of open source software resources, viz., SourceForge. Limiting the search to “Project Management” as the key words, data for the top fifty OS applications ranked by the downloads is obtained and analyzed. Useful classification is developed to assist all stakeholders to understand the state of open source project management (OSPM) software on the SourceForge forum. Some updates in the ranking and popularity of software since
  • On the Evolution of Source Code and Software Defects

    On the Evolution of Source Code and Software Defects

    On the Evolution of Source Code and Software Defects Doctoral Dissertation submitted to the Faculty of Informatics of the Università della Svizzera Italiana in partial fulfillment of the requirements for the degree of Doctor of Philosophy presented by Marco D’Ambros under the supervision of Prof. Dr. Michele Lanza October 2010 Dissertation Committee Prof. Dr. Carlo Ghezzi Politecnico di Milano, Italy Prof. Dr. Cesare Pautasso Università della Svizzera Italiana, Switzerland Prof. Dr. Harald C. Gall University of Zurich, Switzerland Prof. Dr. Hausi A. Müller University of Victoria, Canada Dissertation accepted on 19 October 2010 Prof. Dr. Michele Lanza Research Advisor Università della Svizzera Italiana, Switzerland Prof. Dr. Michele Lanza PhD Program Director i I certify that except where due acknowledgement has been given, the work presented in this thesis is that of the author alone; the work has not been submitted previously, in whole or in part, to qualify for any other academic award; and the content of the thesis is the result of work which has been carried out since the official commencement date of the approved research pro- gram. Marco D’Ambros Lugano, 19 October 2010 ii To Anna iii iv Abstract Software systems are subject to continuous changes to adapt to new and changing requirements. This phenomenon, known as software evolution, leads in the long term to software aging: The size and the complexity of systems increase, while their quality decreases. In this context, it is no wonder that software maintenance claims the most part of a software system’s cost. The analysis of software evolution helps practitioners deal with the negative effects of software aging.
  • Pipenightdreams Osgcal-Doc Mumudvb Mpg123-Alsa Tbb

    Pipenightdreams Osgcal-Doc Mumudvb Mpg123-Alsa Tbb

    pipenightdreams osgcal-doc mumudvb mpg123-alsa tbb-examples libgammu4-dbg gcc-4.1-doc snort-rules-default davical cutmp3 libevolution5.0-cil aspell-am python-gobject-doc openoffice.org-l10n-mn libc6-xen xserver-xorg trophy-data t38modem pioneers-console libnb-platform10-java libgtkglext1-ruby libboost-wave1.39-dev drgenius bfbtester libchromexvmcpro1 isdnutils-xtools ubuntuone-client openoffice.org2-math openoffice.org-l10n-lt lsb-cxx-ia32 kdeartwork-emoticons-kde4 wmpuzzle trafshow python-plplot lx-gdb link-monitor-applet libscm-dev liblog-agent-logger-perl libccrtp-doc libclass-throwable-perl kde-i18n-csb jack-jconv hamradio-menus coinor-libvol-doc msx-emulator bitbake nabi language-pack-gnome-zh libpaperg popularity-contest xracer-tools xfont-nexus opendrim-lmp-baseserver libvorbisfile-ruby liblinebreak-doc libgfcui-2.0-0c2a-dbg libblacs-mpi-dev dict-freedict-spa-eng blender-ogrexml aspell-da x11-apps openoffice.org-l10n-lv openoffice.org-l10n-nl pnmtopng libodbcinstq1 libhsqldb-java-doc libmono-addins-gui0.2-cil sg3-utils linux-backports-modules-alsa-2.6.31-19-generic yorick-yeti-gsl python-pymssql plasma-widget-cpuload mcpp gpsim-lcd cl-csv libhtml-clean-perl asterisk-dbg apt-dater-dbg libgnome-mag1-dev language-pack-gnome-yo python-crypto svn-autoreleasedeb sugar-terminal-activity mii-diag maria-doc libplexus-component-api-java-doc libhugs-hgl-bundled libchipcard-libgwenhywfar47-plugins libghc6-random-dev freefem3d ezmlm cakephp-scripts aspell-ar ara-byte not+sparc openoffice.org-l10n-nn linux-backports-modules-karmic-generic-pae
  • Verso Project Application Report 0.6 Public Document Info

    Verso Project Application Report 0.6 Public Document Info

    Verso Project Application Report Tero Hänninen Juho Nieminen Marko Peltola Heikki Salo Version 0.6 Public 4.8.2010 University of Jyväskylä Department of Mathematical Information Technology Jyväskylä Acceptor Date Signature Clarification Project manager __.__.2010 Customer __.__.2010 Instructor __.__.2010 Verso Project Application Report 0.6 Public Document Info Authors: • Tero Hänninen (TH) [email protected] 0400-240468 • Juho Nieminen (JN) [email protected] 050-3831825 • Marko Peltola (MP) [email protected] 041-4498622 • Heikki Salo (HS) [email protected] 050-3397894 Document name: Verso Project, Application Report Page count: 46 Abstract: Verso project developed a web application for source code manage- ment and publishing. The document goes through the background of the software, presents the user interface and the application structure and describes the program- ming and testing practices used in the project. The realization of functional require- ments and ideas for further development are also presented. In addition, there is a guide for future developers at the end. Keywords: Application report, application structure, Git, Gitorious, programming practise, Ruby on Rails, software project, software development, source code man- agement, testing, WWW interface, web application. i Verso Project Application Report 0.6 Public Project Contact Information Project group: Tero Hänninen [email protected] 0400-240468 Juho Nieminen [email protected] 050-3831825 Marko Peltola [email protected] 041-4498622 Heikki Salo [email protected] 050-3397894 Customers: Ville Tirronen [email protected] 014-2604987 Tero Tuovinen [email protected] 050-4413685 Paavo Nieminen [email protected] 040-5768507 Tapani Tarvainen [email protected] 014-2602752 Instructors: Jukka-Pekka Santanen [email protected] 014-2602756 Antti-Juhani Kaijanaho [email protected] 014-2602766 Contact information: Email lists [email protected] and [email protected].