gvSIG official projects

gvSIG official projects

Version: 1.11
Scope of this document

This document covers the requirements to be fulfilled by a development project in order to become an official gvSIG project.

Exclusions

This document does not cover:

Levels of official development contributions to gvSIG

Before looking at these requirements, it should be noted that there are two official levels that a development can take:

The main difference between the two levels is that one sets requirements related to packaging and distribution of a project, while the other focuses more on development issues (analysis, design, coding, documentation for developers...).

Requirements of an official gvSIG development

The requirements for each level should be considered to be cumulative, except when otherwise stated. This means that the requirements of the basic level must also be fulfilled at the full level.

Some requirements that a project must fulfil to become an official gvSIG project must be met at the start of the validation or certification process, while others may be fulfilled during the course of the process.

Basic level

Requirements to begin the certification process:

  • A contact person with the authority to take decisions about all matters relating to the development shall be provided.

  • The development license must be compatible with GPL v2 or later and any other library that is incompatible with this license must not be used.

    To get recognition as an official project, the documentation submitted with the development project must carry a GPL v2 or later compatible license, or a Creative Commons license that allows commercial use of this document as long as any modifications to the documentation carry the same redistribution restrictions as the original documentation.

  • A report on the library or extension dependencies must be submitted and must indicate the libraries and versions on which they depend. This report must include the dependencies on other gvSIG extensions and libraries and identify these dependencies appropriately.

    Likewise the dependencies on native libraries should also be indicated.

    This document must be kept updated throughout the life of the project.

    If the project uses maven as a means of building units, it is sufficient to deliver the report on the maven site dependencies generated with mvn site. If maven is not being used then use the Project Dependencies template.

  • Each development review must be identified unambiguously. In general terms, a library must contain a version number in the name of the jar, while an extension must have a build name unique to that extension. Two different binaries may not have the same name and version number.

  • The sources from which the binaries are generated and the tools necessary to generate them must be available for public access.

    gvSIG is currently using OSOR forge as space for the project, space which includes a SVN repository for public access in read mode, trackers for bugs and tasks, and so on. If the project does not have the infrastructure necessary for its management, gvSIG can coordinate the creation of a new project for the collaborator.

  • When the sources are downloaded from the source code repository, a README.txt file must exist in the root of the project. This file must include the instructions to compile, deploy and build the installable.

The requirements which must be fulfilled during the certification process are:

  • There must be some analysis documentation that describes the development.

    It is not necessary to describe the design level, but it is essential that the analysis level is described. It includes the description of the main modules and their relation to other gvSIG modules.

  • A repeatable and documented way to create installable packages for the gvSIG extension shall be provided. It's best to use the procedure used by the current gvSIG version for packaging extensions.

  • It must be able to be internationalized using the necessary gvSIG libraries. At the very minimum, it must be submitted in English.

  • A user manual, composed in ReST format and following the rules for writing proper documentation currently in force in gvSIG (Documentation Guide), should be provided. The user documentation that must be submitted includes:

    • User manual
    • Installation manual
    • Credits that must appear in the gvSIG manual when the documentation associated with that project is included in the manual.
  • With respect to testing, the requirements are:

    1. A Test Plan (TP) that covers the new features entirely, at least to the level of test case, must be designed. Both functional and persistence tests should be taken into account. The TP will be loaded into the project's test case management software and this software will be used to run the TP for the first time. It's also possible to request the execution of a test campaign, including regression and persistence tests, which the Department of Software Testing will purpose-design based on the analysis of the impact of the new developments on the rest of the application. Moreover, it is highly advisable to open a new bug ticket for each bug found when running the tests, indicating the actual step in which the bug was detected.

    2. A stabilization phase is necessary in which a developers team and a testers team will work intensively and in a coordinated way to fix bugs, both within the new functionalities and on bugs that appear in the other parts of the application owing to the integration of these functionalities.

    3. When an official development don't pass the test plan for a gvSIG version, that development will not be an official project for that gvSIG version.

    4. A bug and new features management system must be available for public access and any anonymous user must be able to register tickets.

      If the project do not have this kind of management system, it would be able to use the bug and new features management system that OSOR has. This management system allows the project to save the sources, download the binaries and manage its tickets. If it is not possible, as a last resort, all these elements would be able to be included in the bug management system of the gvSIG application.

    See the general outline of the testing procedures

  • There should be a gvSIG plugin for functionality, or groups of related functionalities, from the user standpoint, with an eclipse project for each of the plugins.
  • There should be a clear and understandable policy for maintaining the project's version number.
  • There should be a clear and understandable policy for naming the files of the project's distribution.
  • The installation of a plugin in gvSIG must not overwrite any libraries included in the official release of gvSIG.

There are two templates in ReST format that must be completed and submitted with the basic project data, the project sheet and the project contacts.

Full level

It is not necessary to fulfil the requirements of this level until the end of the certification process.

  • Maven must be used as build environment for the extension or library, using the gvSIG project structure, including the gvSIG criteria for naming packages, artefacts and libraries.

    Moreover, the pom.xml files must include all the necessary data, for example:

    • Description of the project
    • Links to the code repository
    • Links to the mailing lists
    • Developers
    • Etc.
  • There must be complete API documentation through the javadocs, and also a mechanism to deploy them at the site where they are in the gvSIG project. The API documentation shall be written in English.

  • Automated tests covering the extension API or library must be made using JUnit tests.

  • The logic and the user interface must be strictly separated.

  • There must be a strict separation between the API and the implementation, generating separate libraries for the API and the implementation, both for the logic and for the user interface.

  • Existing coding standards should be followed in the project.

  • A guide for developers must be drawn up to document how to use the functionalities. This guide should preferably be written in English.

  • The development documentation must be generated in ReST format.

Starting the paperwork

If you are interested in your development becoming an official gvSIG project you may register a ticket or newsletter using the offical project collaboration request page in OSOR forge.

In the ticket enter a few paragraphs describing the functionality provided by your development, and also attach templates of the project sheet and project contacts. To complete the templates remember to do so from their source code. You can find more information on how to access document sources here.

We will then put you in contact with the appropriate person from the gvSIG project to lead the coordination of tasks required to formalize your development in gvSIG

Change log
Version Description
1.1 Added a link to the dependency report template.
1.2 Replaced the link to the dependency report template by a link to a document that describes how to complete the dependency report template and where to obtain it.
1.2 Added a link to an explanatory document about how to complete the README.txt file to be included with the source code and where to get this file template.
1.2 Added a link to an explanatory document to be submitted as the analysis documentation of the basic level, as well as a link to an example.
1.2 Added links to the project sheets and contacts templates.
1.2 Corrected reference to basic and advanced levels. At one point they where referenced as minimum and high.
1.3 Reworked the first paragraph of the document to better express what an official gvSIG project is.
1.4 Added a requirement that different functions should go on different plugins.
1.5 Added a requirement about the policy related to the version number.
1.5 Added a policy requirement related to the naming of the distribution files.
1.5 Replaced a requirement about following the naming rules for classes by one for following coding conventions.
1.6 Added a new section "Starting the paperwork".
1.6 Corrected spelling and syntax.
1.7 Split the scope section into two, scope and exclusions, and added a link to Contributions and patches to gvSIG code.
1.8 You may not overwrite gvSIG libraries
1.9 Added licence conditions on the submitted documentation.
1.10 Added the point 3 of the testing requirements (If an official development don't pass the test plan for a gvSIG version, that development will not be an official project for that version).
1.10 Added the point 4 of the testing requirements (Each project must have a bug and new features management system and it must be available for public access)
1.10 Description of the different documents that are part of the user documentation that must be submitted: user manual, installation manual and credits.
1.11 Added paragraph about the pom.xml file must be properly completed.

Project Dependencies

Version: 1.1

To specify the dependencies of your project you have to complete the template that exists for that purpose in ReST format.

For the template you have to use the document source code. This can be accessed from the icon at the bottom of the template (more information on how to access document sources can be found here).

If maven is being used as a build tool then the dependency report generated for the project site can be submitted, rather than following the format specified in the template.

The template describes the dependencies the project has at compile time, execution and implementation of tests, as well as transitive dependencies and where to find the libraries that are not already part of gvSIG.

To clarify, libraries that are part of gvSIG should be distinguished from those that are not. Libraries that are part of gvSIG are those that have been built from sources within any of the gvSIG projects. Libraries of other projects, whether used in any gvSIG project or not, are not considered part of gvSIG for the purposes of this template.

The following sections can be found in the template:

Change log
version description
1.1 Modified of the wording of the paragraph describing how to obtain the template

README.txt

versión:1.2

At the root of the SVN project there should be a README.txt file that guides people who download the project on how to compile, deploy, package and translate the project into other languages. There is a template in ReST format that can be used for this purpose.

For the template you have to use the document source code. This can be accessed from the icon at the bottom of the template (more information on how to access document sources can be found here).

The following sections can be found in the template:

Change log
version description
1.1 Modified the wording of the paragraph on how obtain the template.
1.1 Extended the packaging instructions to include the maintenance of the build number and the corresponding tags in SVN.
1.2 Modified the wording of the section on Compilation instructions to make it clearer what should be included.
1.2 Minor changes to the wording of the paragraph describing tags in the section on Packaging instructions.
1.2 Rewrote the paragraph on Version information; added links to the document that describes how to interpret the version number in gvSIG.
1.2 Added a note about the necessity of a policy for naming binaries.

Analysis documentation

Version: 1.1
Analysis documentation for basic level official projects.

When providing analysis documentation for a basic level official project the following sections have to be covered:

Provide a document for each section, presenting as much detail as is required for the project.

It is advisable to follow certain conventions:

In the event of the project providing functionality that can be used by other projects in the form of a library, it is advisable to submit documentation showing how to use these features.

It is preferable to use the ReST format for preparing the documentation, although basic level projects submitted in HTML format will also be permitted.

Analysis documentation similar to that required here can be seen at:

It may be helpful to read the Documentation guide before starting to write the analysis documentation.

Before starting the analysis documentation it is also advisable to contact a member of the gvSIG architecture group to discuss what needs to be done.

change log
version description
1.1 Added a link on how to insert images into the documentation.
1.1 Added the recommendation to contact the GVSIG architecture group before starting the documentation.

Interpreting the gvSIG version number

versión:1.0

The gvSIG version number consists of four numbers:

Note

Note: The adaptation of a plugin to a higher version of gvSIG must always include an increase in the plugin version number, either in the major, minor or revision number.

There should never be two distributions emerging from different sources with the same version number, even if only for internal use. Users should always be able to identify exactly which version they are working with as this is extremely important when reporting bugs.

Use the following format to indicate the version number to users:

<Major-number>.<Minor-number>.<revision-number> build <build-number>

Underscores, "_", can be used instead of points, but never dispense with one or the other to separate the different numbers that make up the version number.

Don't ever use:

These incorrect formats might lead to confusion when future versions are released.

change log
version description
   

Naming binaries for a gvSIG plugin

Version: 1.5

Before discussing file names for the distribution, the following information is required:

Once this information has been collected, the file naming criteria for the distribution can be reviewed.

The first criterion is that the entire file name must be in lower case.

The format to use for the name is as follows:

gvSIG-desktop-<gvsig-version>-<name>-<major-number>_<minor-number>_<revision-number>-<build-number>-<state>-<platform>.<zip|exe|bin>

Where:

Warning

The platform identifier "i586" is being evaluated and an alternative that better identifies the platform is being considered. While most identifiers currently distinguish between 32 bit and 64 bit architecture rather than between i586 or i686, we propose using x86 and x86_64.

For source distributions the format will be:

gvSIG-desktop-<gvsig-version>-<name>-<major-number>_<minor-number>_<revision-number>-<build-number>-<state>-src.zip

Finally, when distributing formatted versions of the documentation these should be in PDF format and should be named as follows:

gvSIG-desktop-<gvsig-version>-<name>-<major-number>_<minor-number>-man-v<man-version>-<lang-code>.pdf

Where:

For source distributions and documentation no distinction is made between platforms.

change log
version description
1.1 Added gvsig-version.
1.1 Added the status.
1.2 Corrected a formatting error. The location of the state was incorrect.
1.3 Added devel as an option for state.
1.4 Changed the literal gvSIG at the start of the file name to gvSIG-desktop and modified the platform support to all.
1.5 Substituted status with state and added a new state testing.

Contributions and patches to the gvSIG code

Contributions and patches to the gvSIG code

Version: 1.2
Scope of this document

This document aims to give guidance on the steps to follow to make changes to the existing code in gvSIG.

The contributions to the gvSIG code are mainly divided into three types:

  1. Bugs. Bug fixes in the existing feature in gvSIG.
  2. Improvement of a feature finishing. They are small improvements on existing feature in gvSIG.
  3. New features. Contribution of new feature or modifications to existing code to develop new feature externally.

Since these three ways to contribute to the gvSIG code do not follow exactly the same channels and procedures, we will describe them separately.

A common theme to the forms to contribute to the gvSIG code is that you must surrender the authorship rights of the code contribution to the gvSIG project, as described in the documents What is the gvSIG CLA? and the Contributor License Agreement.

Exclusions

This document does not cover the requirements to be met by a project that provides a new plugin to gvSIG, for this we recommend you to consult the Official gvSIG Projects.

Bugs

If you have detected a bug in the application and have implemented to correct code to fix it, you can contribute it to the project so this is included in future versions of the application.

Not always all corrections will be accepted, sometimes for a lack of resources for inclusion in the review, others for disagreements over whether that implementation is adequate or not to correct the bug. Keep in mind that sometimes the correction of a small bug can give rise to unwanted effects in other parts of the application.

You must complete two tasks to make corrections and fix a bug:

Important

If the code modification is proposed by a user with permission to commit, it will not be necessary to attach a patch, instead simply leave a comment with the review number that applies to the change.

It is also advisable to review the document What should I do to fix a bug?.

Before you upload changes, you must wait until your ticket is approved and assigned.

This means that for all corrections a ticket should be registered, approved and allocated.

Remember that the gvSIG project resources are limited and we can not always act immediately on the tickets received. We will try to respond as soon as possible.

Improvements in a feature finishing

We understand that sometimes there are a number of small changes that although they are not considered errors or bugs; it would be good that they are made on gvSIG. They can be as simple as changing the default option of a dropdown menus or the position of a menu option which it seems more logical somewhere else. They are not errors as such because the application works as designed. They are really small improvements in the existing feature.

The steps to follow to make such amendments to the code will be similar to those to be followed during the contribution of code for a bug, with the only exception that instead of using the gvSIG bug registry it should be used the New request for features .

New Features

When implementing a new feature in gvSIG it must be noted that, in general, new features are incorporated in the form of new plugins, so from the user point of view to add a new feature does not normally requires going through this process. The simplest way is to add the new feature to the unofficial gvSIG catalogue or to follow the procedures described in Official gvSIG Projects so it is included as an official project.

So ... When do we follow these procedures?

We should apply this procedure when in order to add our feature we have to modify parts of gvSIG, usually adding new extension points. The features from the user point of view will be kept in a separate plugin, and the necessary changes will be introduced in gvSIG so the plugin works as designed.

To provide sufficient code to gvSIG that would allow us to develop our plugin, we should request it through the tracker in New request for features. There we will register a ticket with a description of what we want to do, attaching the code as a patch or patches, with the implementation of it.

Before we develop our feature we should register the ticket, describing:

In the ticket you must mark in the Has patch field a yes so that development team clearly identifies the ticket as a request for feature that aims to provide code to gvSIG.

Note that:

Once the petition is read, you can be requested to provide more information or to make some changes in some part of what it claims to do, and finally, to be asked for the code that implements it, as a patch or patches, to be attached to the ticket.

Important

If the code modification is proposed by a user with permission to commit, it will not be necessary to attach a patch, instead simply leave a comment with the review number that applies to the change.

Before you upload changes, you must wait until your ticket is approved and assigned.

Remember, the first time you must send us the document with the CLA surrendering your copyright on the code that you are giving to gvSIG. More information about this can be found in the Contributor License Agreement document.

Change registry
version Description
1.1 (translation pending) Añadidos los valores a los que deben dejarse los campos state y resolution de un ticket.
1.2 Update references from OSOR to the https://devel.gvsig.org/redmine site

What is the gvSIG CLA?

Version: 1.0

Tip

This document is based on the OpenBravo legal aspects document.

The current gvSIG official projects copyright holder is the gvSIG Association. Any contribution to the gvSIG project requires to sign our contributor's agreement and send it by regular mail or by fax to gvSIG (this is an unfortunate consequence of copyright law in some jurisdictions). This requirement does not apply to external modules, localizations, documentation, except if they are contributed to us. It only applies to contributions that will be part of the core products.

The objective of contributor agreement is to protect the integrity of the project, its users and developers. The contributor agreement transfers the contributor's copyright to gvSIG who grants a non-exclusive license back to allow the contributor to use his/her own work. The rationale behind the agreement is:

  1. In case of a legal claim, having a single copyright owner makes it easier to defend the interests of the gvSIG users and developers. The gvSIG Association is committed to defend gvSIG projects in the event of any claim or infringement by third parties.
  2. The gvSIG Association can relicense its works under any other license in the future. When starting an open source project, the choice of license is intended to be permanent, but the experience of the past few years is that the ability to relicense a project is a useful tool in meeting challenges for open source projects. Not having that flexibility may be a drawback. Without the agreement, every single contributor must be contacted and unanimity reached in order to relicense a code base, or parts of the code must be reimplemented. This is true for all but the most permissively-licensed open source projects.
  3. The contributors assert that their contributions are original and not protected by any patents. It guarantees to all contributors in the project that all the contributions are original.

Contributor's agreements are standard procedure in open source projects followed by projects ranging from the Free Software Foundation to the OpenOffice.org project, including the Apache project, on which this agreement is loosely based.

If you are not contributing code within the framework of a company or an institution, (i.e. your work is done as an individual), you have just to sign the contribution agreement and send it to the gvSIG Association.

If you are a company, please ensure that someone authorised to sign on behalf of the company signs the agreement and lists the names of people that agreements covers. This is usually done by a senior manager in the organization. This helps to reduce the number of individuals agreements to be signed.

If you have any question regarding this contract please contact us gvsig-legal@gvsig.com.

References

Similar pages of other free software projects:

Change log
Version Description
1.0 First published version of the document

CLA status

Organizations
Organization name Date received
LSI (UJI) 2011/06/01
ai2 (UPV) 2011/06/01
DISID 2012/03/28
Laboratorio de Bases de Datos. Universidade da Coruña 2012/04/24
Software Colaborativo TBD
Prodevelop TBD
CartoLab TBD
iCarto TBD
Individual contributors
Name Date received
Fernando Pinotti (UPV) 2011/09/04
Fernando González 2012/03/26
Antonio Falciano 2012/08/02
César Martínez Izquierdo 2012/09/28

gvSIG code contribution profiles

gvSIG code contribution profiles

Version: 1.0

Table of contents

Introduction

This document integrates the description of the different contributor profiles that can participate on the development of gvSIG, presenting at the end on a pretty schematic way the main workflows available when contributing software code to gvSIG.

Described profiles are:

Profiles
External developer

Any community member interested on contributing patches. He doesn't have to had a strong commitment with the project and he should be able to do small contributions without too much barriers.

Project developer

A developer with write permission on the whole gvSIG source repository or at some section. He is a developer strongly committed to the project, providing code regularly, so he needs to be comfortable committing changes.

To obtain this role a request to the TSC Board will be presented and will pass with simple majority if (s)he fulfil the established metrics. If the metrics are not fulfilled, the motion will pass with a qualified majority of 3/4. This role can be lost if a request to the TSC Board is presented and will pass with the same criteria that to get the profile.

Maintainer

It's the person in charge to any task to coordinate the development of a subsystem. They will deal with tickets from external developers, or reassign them to project developers. On the other hand, from a technical point of view they will take care to maintain a high cohesion and loose coupling in the subsystem they maintain.

To obtain this role a request to the TSC Board will be presented and will pass with simple majority if (s)he fulfil the established metrics. If the metrics are not fulfilled, the motion will pass with a qualified majority of 3/4. This role can be lost if a request to the TSC Board is presented and will pass with the same criteria that to get the profile.

Reviewer

Is the person in charge of the review and evaluation of the changes on the subsystems started by someone's request or because a periodic supervision.

He's objective is to maintain stability and robustness of the application as a whole, focusing specially on subsystem interfaces and the collaborations between them.

She is a developer with an special sensitivity that encourages her to look with criticism the code, looking more for the impact of changes on the system than on the usefulness of the functionality that code adds.

This profile doesn't requires specific knowledge on the module affected by any change, nor a deep knowledge on gvSIG architecture, and they won't be assigned to any specific subsystem inside gvSIG.

An important note in that a reviewer is not to support any module or subsystem maintainer at all. If you understood that, please read carefully the maintainer description.

To get or loose this profiles the same rules that for maintainers will be applied.

Tester

Note

This tester description is not complete, here there are relevant information about their relation with the other roles described on this document.

A tester is a person in charge of verifying that the application behaves on the way it is noted on a ticket. If the ticket is about a bug fix, it will contain the code, but also all the relative information about how to reproduce the error and how to verify it has been fixed. If the ticket is about a new functionality, it will contain a description of its requirements and how the tester can assure they are fulfilled.

To qualify for this profile an appointment by the testing manager is the only requirement.

Software architecture support

Is a member of the gvSIG software architecture team who can be asked by any developer for advice or help in assessing the impact of a given change.

gvSIG code point of view of every role

Every role related with the development and interaction with the source code of gvSIG has a different point of view of the project. It can be of high level or in-depth. For example, a high level perspective will see a gvSIG product as a set of subsystems that interact trough a group of well defined interfaces. A low level point of view is focused on a subsystem implementation. With this definition in mind, next table shows the roles points of view on the gvSIG code:

Role Visibility
Software architecture support They have a general point of view of the application, looking at it as a whole.
Maintainer He looks for his module code, as well as any API his module interacts
Reviewer He looks at interfaces or even methods. He evaluates the impact of changes on the semantics, interfaces, method signatures or their context.
Rights and Obligations

The following are the duties and rights of each of the profiles:

Role Rights and Obligations
External developer
  • To open new tickets attaching code patches.
  • To know about Contributions and patches to the gvSIG code recommendations
  • To know about coding conventions used by the project
  • When your contribution modifies any API, the corresponding javadocs will be updated accordingly
  • If your contribution breaks any existing automated test, they will be updated accordingly
  • If the package maintainer requests it, you will provide additional or updated tests in order to cover the new behaviour contributed
  • If your contribution changes the Graphical User Interface, the maintainer could ask for an update on the user documentation to accept the patch
Project developer
  • Create new tickets attaching patches or references to changes at source code repository
  • Commit code to the source code repository (always with a ticket assigned to the commit)
  • To know about Contributions and patches to the gvSIG code recommendations.
  • To know about coding conventions used by the project.
  • To know when is allowed to commit changes to the source code repository and when is not. The project managers will notify about this timing on mailing lists.
  • To know well the development documentation.
  • Any uploaded code will have updated also the javadocs.
  • If your contribution breaks any existing automated test, they will be updated accordingly. Likewise, you will provide additional or updated tests in order to cover the new behaviour contributed.
  • Provide to the testers all the information they could need to validate the change, as well as update the test cases (nowadays this last requirement is not possible by technical impediments, but it will be needed as soon as they are solved).
  • If the package maintainer requests it, you will provide additional or updated tests in order to cover the new behaviour contributed
  • If your contribution changes the Graphical User Interface, the maintainer could ask for an update on the user documentation to accept the patch.
Maintainer
  • Create new tickets attaching patches or references to changes at source code repository
  • Commit code to the source code repository
  • Assign tickets to reviewers
  • Ask to software architecture team about the impact of a code change
  • Assign tickets to developers to commit changes to the source code repository or to ask for more information to the community contributor. That doesn't avoids revision, it's just to speed up the process if it has to be done.
  • Auto-assign a tickets with an attached patch and commit it or ask for any change to the contributor. This doesn't remove revision, it just speeds up the process if it has to be done.
  • To assure that tickets have all the information needed by testers to validate the change, and if this is not true, to claim for it to the developer that contributed the change.
  • As a maintainer is also a project developer, (s)he will have the same rights and obligations besides their specific ones.
  • To assure that tickets received on his subsystem are treated accordingly (assign tickets to reviewers or to developers)
  • To reject tickets without updated javadocs if they are needed (always asking first to the developer if the first time they weren't provided)
  • To reject tickets that broke any automated test existing at the project of the contributed code (always asking first to the developer if the first time they weren't provided)
  • To reject tickets with code that doesn't follow the project code conventions (always asking first to the developer if the first time they weren't followed)
  • To reject tickets that don't specify how a tester can verify the change solves the incorrect behaviour (always asking first to the developer if the first time it wasn't provided)
  • Maintain the configuration, information and documentation about the building process of the subsystem. If maven is used, assure that besides compilation, deploy mechanisms are working, site generation, etc. as well as the information stored at pom.xml file: developers, description, etc.
  • Be responsible on the application on corrections and new functionalities between different live versions of gvSIG, at least against superior versions. It's not necessary to apply or ask for changes on all versions, but at least (s)he has to create the tickets in order to not lose the changes. For example, there is a bug with a patch for gvSIG Desktop 1.x, it should be applied or at least to create the corresponding ticket for 2.x.
  • He is in charge to maintain a high cohesion and loose coupling in the subsystem he maintains
  • He is in charge of the source code version control he maintains
  • He has to coordinate changes to be ready for next releases of the application
  • He has to be aware of the dependencies of the subsystem he maintains
  • He has to maintain the user documentation updated, asking to the ticket creator for additional information or needed screenshots
  • He has to know about the project procedures associated with the user documentation generation
  • He has to know about the procedures associated with the process of releasing a new version of the project, binaries naming, where they have to be placed, how to update libraries,....
Reviewer
  • Create new tickets attaching patches or references to changes at source code repository
  • Commit code to the source code repository
  • Accept or reject tickets with code contributions
  • Ask to software architecture team about the impact of a code change when knowledge of gvSIG as a complete systems are needed.
  • Ask the maintainer when the code contribution is related with a subsystem with an assigned maintainer.
  • Review assigned tickets
  • Report on the ticket any detected problem on the code
  • Reject any ticket that broke existing automated tests on the project where the changes will be applied.
  • Reject any ticket without the proper documentation (javadocs) on the code changed or contributed.
  • Reject any ticket with code that doesn't follow the gvSIG code guidelines
  • Reject any ticket with code but without instructions for the testing team about how to verify that code works as expected
  • Fix small problems that the code contribution can arise, annotating that on the same ticket
  • If the ticket is a patch an the change is accepted, commit it to the source code repository
  • Inform the maintainer when (s)he can not attend an allocated ticket for review
Tester
  • To mark a ticket as a non resolved
  • To mark a ticket as a non valid
  • To mark a ticket a validated
  • Review assigned tickets by the testing manager and mark them as validated, non solved or waiting for more information
Software architecture support
  • Assign tickets to be reviewed.
  • Assign tickets to the reviewers to be reviewed on a given version stabilisation period, on those modules where there is no assigned maintainer.
  • Attend developers help requests
Activities restrictions

Next table shows what is not allowed to every role.

Role Restricitons
External developer
  • To commit code directly to the source repository
  • To approve a ticket with a patch
  • To auto-assign a ticket
  • To validate a ticket
Project developer
  • To approve a ticket with a patch or code contribution
  • To assign tickets
  • To validate tickets
Maintainer
  • Review his own patches or code contributions
Reviewer
  • When accepting code, to take decisions about functionality
  • Review their own tickets
  • Commit code from a ticket that has not be assigned to him by a maintainer or the architecture team
Role metrics

Next table shows the different metrics to take in account to obtain a role.

Role To obtain a role
Project developer
  • Provide at least three code patches
  • Participate on at least two gvSIG product revisions
  • To exists at least two reviewers, maintainers or software architecture team members supporting the candidate, specially those reviewers that had worked on candidate contributions.
Maintainer
  • Participate as a project developer on at least the complete period between two gvSIG revisions.
  • Participate actively on the wanted module, at least with 6 (six) code patches.
  • To exists at least one reviewer, maintainer or software architecture team member supporting the candidate, specially those reviewers that had worked on candidate contributions.
Reviewer
  • Participate as a project developer on at least the complete period between two gvSIG revisions.
  • To exist at least one reviewer, maintainer or software architecture team member supporting the candidate, specially those reviewers that had worked on candidate contributions.

This table shows some considerations to be taken in account when losing a role:

Role To lose a role
Project developer
  • Provide at least four consecutive code patches rejected after their revision by a maintainer or reviewer
  • Inadvertently repeated contributions that cause other errors in the application
  • Two years of no participation
  • If there is a clear dissociation with the project
Maintainer
  • Provide at least four consecutive code patches rejected after their revision by a reviewer or a software architecture team member
  • Two years of no participation
  • If there is a clear dissociation with the project
  • Four or more contributions to a module of an specific version, without applying or creating a new ticket for the superior version
Reviewer
  • Provide at least four consecutive code revisions where the software architecture team considers that the API syntax or semantics has been altered, affecting the behaviour of any other part of the application
  • Two years of no participation
  • If there is a clear dissociation with the project
  • If there is a neglect of their duties clearly and repeatedly
Use cases and work flows overview

Warning

In development

Use case 1: new ticket with patch
  • A new ticket is created with the bug or new functionality despription
  • The developer adds a source code patch
  • If the ticket is managed by a reviewer:
    • The maintainer or architecture team member assigns the ticket to a reviewer
    • If the reviewer detects something wrong, he adds a note on the ticket and if he sees that the contributor would solve it, he asks for fixing at the same ticket
    • When the reviewer agrees with the patch, he commits it to the SVN and updates the ticket, changing the status to reviewed
  • If the ticket is managed by a maintainer
    • The maintainer or architecture team member assigns the ticket to a maintainer
    • The maintainer commits the changes to the SVN and updates the ticket
    • The maintainer or an architecture team member assigns the ticket to a reviewer
    • If the reviewer detects something that can be wrong, informs of this on the ticket and ask the maintainer about fixing it
    • When the reviewer is happy with the changes updates the ticket to reviewed
  • If the ticket is managed by a project developer
    • The maintainer or architecture team member assigns the ticket to the project developer
    • The developer commits the changes to the SVN and updates the ticket
    • The maintainer or architecture team member assigns the ticket to a reviewer
    • If the reviewer detect something that can be wrong, informs of this on the ticket and ask the developer about fixing it
    • When the reviewer is happy with the changes updates the ticket to reviewed
Use case 2: ticket management by a project developer
  • The developer will firstly contact the project maintainer using the ticket comments to inform about his interest on solving that bug
  • The maintainer assigns the ticket to the developer
  • The developer commits the changes to the SVN and updates the ticket
  • The maintainer or architecture team member assigns the ticket to a reviewer
  • The reviewer checks the code and if everything is ok changes to ticket to reviewed
Use case 3: ticket management by a maintainer
  • The maintainer assigns to himself the ticket
  • The maintainer commits the changes and updates the ticket
  • The maintainer or an architecture team member assigns the ticket to a reviewer
  • The reviewer checks the code and if everything is ok changes the ticket to reviewed
Change registry
version Description
1.1 Added information about the workflow (to be reviewed)

Modules gvSIG-desktop

gvSIG-desktop v1
Proyect Maintainer Email
Applications    
  • appCatalogAndGazetteerClient
J.Piera jpiera@prodevelop.es
  • appgvSIG
Fran Peñarrubia fpenarru@gmail.com
Extensions    
  • extAddEventTheme
   
  • extAnnotations
   
  • extArcims
   
  • extCAD
Fran Puga fpuga@cartolab.es
  • extCatalogAndGazeteer
J.Piera jpiera@prodevelop.es
  • extCenterViewToPoint
Nacho Varela nachouve@gmail.com
  • extDataLocator
Fran Peñarrubia fpenarru@gmail.com
  • extDerivedGeometries
   
  • extDwg
   
  • extExpressionField
Fran Puga fpuga@cartolab.es
  • extGeoProcessing
   
  • extGeoProcessingExtensions
   
  • extGeoreferencing
   
  • extGPE-gvSIG
   
  • extHelp
   
  • extHyperlink
Pablo Sanxiao psanxiao@icarto.es
  • extI18n
   
  • extIconThemeBase
   
  • extJCRS
   
  • extJDBC
Fran Peñarrubia fpenarru@gmail.com
  • extLayerLoadingOrder
Fran Puga fpuga@cartolab.es
  • extOracleSpatial
   
  • extProjectBackup
   
  • extQuickInfo
   
  • extQuickPrint
   
  • extRasterTools-SE
   
  • extScripting
   
  • extSDE
   
  • extSelectionsTools
   
  • extSextanteGvsigBindings
   
  • extSymbology
Fran Peñarrubia fpenarru@gmail.com
  • extTableExport
   
  • extTableImport
   
  • extTableSummarize
   
  • extWCS
   
  • extWFS2
J.Piera jpiera@prodevelop.es
  • extWMS
Fran Peñarrubia fpenarru@gmail.com
Frameworks    
  • _fwAndami
   
Libraries    
  • libArcIMS
   
  • libCorePlugin
   
  • libDriverManager
   
  • libDwg
   
  • libDXF
   
  • libExceptions
   
  • libFMap
Fran Peñarrubia fpenarru@gmail.com
  • libGDBMS
Fran Peñarrubia fpenarru@gmail.com
  • libGeoUtils
   
  • libGPE
   
  • libGPE-GML
   
  • libGPE-KML
   
  • libGPE-XML
   
  • libInternationalization
   
  • libIverUtiles
   
  • libjCRS
   
  • libProjection
   
  • libRaster
   
  • libRemoteServices
   
  • libTopology
   
  • libUIComponent
   
  • org.gvsig.installer.app.extension
Nadal francisco_nad@gva.es
Another gvSIG 1.X proyects    
  • install
Fran Puga fpuga@cartolab.es
  • binaries
   
  • ChartLegend
   
  • NavTable
Andrés Maneiro amaneiro@icarto.es
  • ConsecutiveNumberExtension
   
  • CopyPasteGeom
   
  • NewGeoprocess
   
  • SelectDuplicatesExtension
   
Proyects not incluided in gvSIG 1.X    
  • extGraph
Fran Peñarrubia fpenarru@gmail.com
  • 3D
Jordi Torres jtorres@ai2.upv.es
  • Animation
Jordi Torres jtorres@ai2.upv.es
gvSIG-desktop v2
Proyect Maintainer Email Comments
  • appCatalog
  • extCatalog
     
  • appGazetteer
  • extGazetteer
     
  • appgvSIG
     
  • build
  • org.gvsig.core.maven.dependencies
     
  • extCenterViewToPoint
     
  • extDalTransformEventTheme
     
  • extDalTransformJoin
     
  • extDataLocator
     
  • extDwg
  • libDwg
     
  • extEditing
     
  • extExpressionField
     
  • extGeoDB
     
  • extGPE-gvSIG
     
  • extHelp
     
  • extI18n
     
  • extIconThemeBase
     
  • extJCRS
  • libjni-proj4
     
  • extWFS2
     
  • _fwAndami
     
  • _fwAndami-updater
     
  • libCompat
     
  • libCorePlugin
     
  • libDXF
     
  • libEvaluator_SQLJEP
     
  • libFMap_controls
     
  • libFMap_dal
     
  • libFMap_daldb
     
  • libFMap_dalfile
     
  • libFMap_dalindex
     
  • libFMap_geometries
     
  • libFMap_mapcontext
     
  • libInternationalization
     
  • libIverUtiles
     
  • libProjection
     
  • libRemoteServices
     
  • libUIComponent
     
  • org.gvsig.about
     
  • org.gvsig.annotation
  • org.gvsig.annotation.app
     
  • org.gvsig.app.document.layout.app
     
  • org.gvsig.app.document.table.app
     
  • org.gvsig.arcims
  • org.gvsig.arcims.feature.extension
  • org.gvsig.arcims.image.extension
     
  • org.gvsig.daltransform.app.mainplugin
     
  • org.gvsig.educa.batovi
  • org.gvsig.educa.thematicmap
  • org.gvsig.educa.thematicmap.app
José Manuel Vivó jmvivo@disid.com  
  • org.gvsig.exportto
  • org.gvsig.exportto.app
     
  • org.gvsig.external.jedit
     
  • org.gvsig.external.jump
     
  • org.gvsig.external.raven
     
  • org.gvsig.geocoding
  • org.gvsig.geocoding.extension
     
  • org.gvsig.geometrymeasurement.app
     
  • org.gvsig.geoprocess
     
  • org.gvsig.hyperlink.app
     
  • org.gvsig.installer
  • org.gvsig.installer.app
     
  • org.gvsig.metadata
  • org.gvsig.metadata.app
     
  • org.gvsig.mkmvnproject
     
  • org.gvsig.newlayer
  • org.gvsig.newlayer.app
     
  • org.gvsig.normalization.extension
     
  • org.gvsig.oracle
     
  • org.gvsig.personaldb
     
  • org.gvsig.raster
  • org.gvsig.raster.tools
  • org.gvsig.raster.cache
  • org.gvsig.raster.tilecache
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.ermapper
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.gdal
  • org.gvsig.jgdal
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.lizardtech
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.mosaic
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.netcdf
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.postgis
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.wcs
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.wms
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.wmts
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.scripting
  • org.gvsig.scripting.app
     
  • org.gvsig.selectiontools.app
     
  • org.gvsig.symbology
  • org.gvsig.symbology.app
     
  • org.gvsig.testplan.app
     

Add a package to the repository of gvSIG

Warning

FIXME. Direct google translation.

version:1.2

Scope

This document specifies the procedure to add a new package to the package repository of gvSIG project whether a package is hosted on servers project or not.

Exclusions

This document does not cover:

Requirements

To add a package to the package repository of gvSIG must create the installation package and deliver the file ". gvspki" generated. You can find documentation on how to build the package for a gvSIG plugin in the document Generación desde el plugin de instalación . Ask on the development list if you have doubts.

The package must be met:

In addition to these requirements is highly recommended:

Expclusion a package repository

This section describes why a package may not be included in the package repository gvSIG or eliminated if already formed part of it.

How to start the paperwork

If you have already created the installation package associated with their plugin (. gvspkg and. gvspki) may request inclusion in the repository gvSIG package by the trac ticket Addons repository requests . To this should be registered as a user of the gvSIG_platform.

You must add the fields filled out a ticket:

Make sure the download-url entry package.info package that provides is correct and accessible from the internet, otherwise the package may not be included in the package repository gvSIG.

Do not assign the ticket to anyone and leave the other fields with the values defects have a ticket.

Note that since the project if you have questions about has made the request was answered on the same ticket by adding comment.

ChangeLog
Version Description
1.1 Changes in the section "How to start the paperwork* to adapt to the new infrastructure of gvSIG (redmine).
1.2 Changes in the section "How to start the paperwork*, has changed the way the file is provided as gvspki, be attached to the ticket to put your url in the description.