Personal tools
You are here: Home gvSIG Projects gvSIG Desktop Documentation Developers documentation How to contribute in gvSIG?
gvSIG Desktop
gvSIG Desktop

Cached time 11/21/13 16:03:32 Clear cache and reload

 



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:

  • The conditions a project must meet to be included in the official distribution of the gvSIG application.

    A project must be an official gvSIG project before it can be included in the official gvSIG distribution, but fulfilling this requirement is not automatically guaranteed.

  • Modifications or contributions to existing gvSIG code.

    If you want to contribute code to an existing gvSIG project consult the document Contributions and patches to gvSIG code.

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:

  • Basic level. This level integrates testing, user documentation (but the gvSIG project is not responsible for maintaining it), fixing of bugs, adding of new functionalities or adapting them to a new version.

    If it is decided to include a development in an official release and the new development does not compile, has a run-time failure or makes another extension fails, the contributor who created this extension will be informed and if the contributor does not devote resources to fix it, the development will be removed from that version.

    This level hardly covers restrictions on packaging, documentation and user testing. Moreover, it is not necessary to fulfil the rules or recommendations regarding design and implementation. So, the costs of maintaining the development for members who are working with gvSIG may be quite high.

  • Full level. The contribution includes testing as well as user and development documentation. The gvSIG project may take charge of fixing some bugs and its adaptation to new versions that are released, depending on the resources the project has available at that time.

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:

  • Project Dependencies

    When specifying dependencies, these should be dependencies on other libraries. This includes both libraries that are already part of gvSIG, as well as new libraries that the project needs.

    Other projects in the eclipse workspace should not be indicated as dependencies. If this does occur, an indication must be given of how to compile the library dependencies generated by these projects.

    • Compile

      This is where the compile-time dependencies of the project are specified.

    • Runtime

      The runtime dependencies of the project are specified here.

    • Test

      Here the project dependencies for executing the project tests are specified.

    For gvSIG projects prior to version 2.0.0, and for those that don't use maven as a build mechanism, if you are not sure which libraries are required then this should be indicated in all three sections. However, whenever the libraries are known they should be correctly specified.

    • Dependency Tree

      In this section the relationships between the various libraries in the project are specified. This is a view, in the form of a tree, of the each of the transitive dependencies in the project.

      For the dependencies on libraries that are already part of gvSIG it is not necessary to specify their transitive dependencies, as is mandatory for all other libraries in the project.

    • Licenses

      In this section list the different licences of libraries that are used by the project but which are not part of gvSIG.

      We will have an entry for this licence, and the various libraries that ship with it.

      Don't include libraries that already form part of gvSIG.

      If there are libraries for which the licence is not known, list the licence entry as unknown, bearing in mind that this might result in the project not being accepted as an official gvSIG project.

    • Dependency Repository Locations

      In this section indicate the location of the official repository of those libraries that are not of gvSIG. This is the location from where the version of the library used by the project can be downloaded.

      If maven is being used as a development tool, indicate one of the official maven repositories from which the library can be downloaded.

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:

  • Introduction

    Include a list of the different sections that can be found in this file.

  • Version information

    Specify the following:

    • Files that must be updated every time the version number of the project needs to be updated.
    • The operations that must be performed to update the version number.
    • If the version number format or update policy of gvSIG is not followed, the format being used should be described.

    It is recommended that you read the document Interpretation of the gvSIG version number.

  • Compilation instructions

    You should include:

    • Instructions on how to configure the eclipse workspace
    • Instructions for compiling the project
    • Instructions that allow a developer to deploy it as a framework for a gvSIG plugin.

    Remember to specify whether to download and set up a workspace with gvSIG, or if the extension must be compiled as a gvSIG binary.

  • Packaging instructions

    Here you should include instructions on how to package the project, both as a separate extension, and in a gvSIG installation.

    The packaging instructions should include both the packaging process itself, such as maintaining a unique version number, and the updating of the corresponding files in the SVN in order to reflect the increase in version number (where appropriate).

    There should also be instructions for generating a tag in the version control system for the sources corresponding to this version number, detailing the naming policy to use for naming the tag.

    You must follow a well-defined policy for the name given to the binary distribution. It is essential that the binary name specifies:

    • The project.
    • The version.
    • The platform.

    If you follow a naming policy for the binary distribution that differs from that of gvSIG then this must be indicated in this section. You can view the gvSIG naming policy in the document Binary names for a gvSIG plugin.

  • Notes on internationalization

    This contains the following subsections:

    • Location of the translation strings

      Specify the location of the translation strings used by the project, as well as the languages that are available.

    • What should be done to include a new language

      Indicate what needs to done to add a new language to the strings that already exist in the project.

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:

  • Introduction.

    Provide a document entitled "Introduction", containing a brief description of the project and indicating the aims covered and not covered.

    This introduction should consist of three or four paragraphs describing briefly the objectives to be covered.

  • Context.

    Provide a block diagram showing the components of the project in relation to gvSIG and a model of its layers, user interface/gvSIG application, geo/fmap logic, library support.

  • Overview.

    Present an overview of the major components of the project and the relationships between them. Focus mainly on the components making up the project's API, ignoring components specific to the implementation. Also state the relationship between these components and those of gvSIG.

    Normally included are:

    • A few paragraphs containing a brief text description of the model and its components.
    • A diagram that shows graphically the relationships between the components, clearly distinguishing the project components from those components already existing in gvSIG.
    • A brief description of each of the components appearing in the diagram. A paragraph is usually sufficient for each of the artefacts in the model.
    • If the diagram is very complex, functionalities should be grouped into more general components, so that complex components in the diagram can be decomposed into others, leading to a greater understanding of the model. In this case, include a list of the components operating in the model.
  • Detailed view of components.

    For each of the components specified in the overview and that can be used, include a description and a diagram, similar to that in the Overview but for the component in question.

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

It is advisable to follow certain conventions:

  • Normally attributes or methods aren't specified for the different components in the diagrams since this documentation is analysis documentation and is not about design. Inclusion of design features at this level would obscure the understanding of the model.
  • Diagrams are read from top to bottom and from left to right. With this layout, for example, inheritance can be indicated with super-classes at the top and sub-classes at the bottom, or in the case of one to many relationships, the master entity is shown at the top and the details are shown below or to the right.
  • Design diagrams so that they are higher than they are wide (i.e. in portrait layout), and try to have their components at the top and not across the diagram. This is so that if the documentation is printed there will not be much loss in quality if the diagrams are scaled to fit an A4 page.
  • Don't scale the diagrams for inclusion in the documentation. If they are too large they will be split into a series of diagrams.
  • Try to cross lines as little as possible and don't overlap them with other lines.
  • Try to use different entity background colours for grouping sets of functional entities, and provide a legend for identifying the functions.
  • Use stereotypes to identify interfaces and abstract classes.
  • If an analysis of the implementation's javadocs accompanies the documentation, then a link to the javadoc should be used when referencing one of these entities.
  • When inserting diagrams into the documentation, use PNG format with a reduced colour palette (16 or 32 colour palette) in order to reduce the size of the document when accessing it via the web. For more information on this go to inserting images into documentation.

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:

  • Major number. This is increased more for strategic than for technical reasons.
  • Minor number. This number is increased when a new distribution adds new features when compared to the previous version.
  • Revision number. This increases when a distribution is created that does not add new features, or they are irrelevant, when compared to the previous version. This distribution is normally for bug fixes.
  • Build number. This increases each time a distribution is built, whether it is a public distribution or an internal build made for testing purposes.

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.

  • 1.2.0 build 3

Don't ever use:

  • 120 build 3
  • 12 build 3

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:

  • The short name or code of the plugin.
  • The version number of the distribution. Read the document Interpreting the gvSIG version number to familiarise yourself with gvSIG version numbers.
  • The platforms for which the distribution will be built.
  • The status of the development: alpha, beta, RC, final, ...
  • The version of gvSIG for which it will be packaged.

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:

  • gvsig-version is the gvSIG version number specified in the following format:

    <major-number>_<minor-number>
    

    Neither the revision nor the build number is specified as no changes to the API are expected between versions.

  • name is the project's short name or code.

  • major number, minor-number, revision-number, and build-number identify the version of the project. Depending on the gvSIG version for which the extension will be published, we advise to use a different major-number as well. E.g., if the extension is available for gvSIG 1.x as well as gvSIG 2.x, the extension's major-number could be set to 1 and 2 respectively. The important thing is for them to be different to avoid confusion, not to be the same numbers as the gvSIG ones.

  • state can be:

    • devel, for versions under development.
    • pilot, for pilot plugins. Pilots are usually made available for testing, don't have full functionality and might contain bugs.
    • prototype indicates a proof of concept that shows how developers plan to undertake a development. Future developments might not necessarily follow the same track.
    • testing is used for versions that need to be tested prior to moving to alpha, beta, etc., stages.
    • alpha.
    • beta.
    • RC followed by a number (RC1, RC2, ...) identifies release candidates prior to the final version of the product.
    • final identifies the final version of the plugin.

    A development doesn't have to go through each of these stages but the distribution state should be specified.

  • platform contains information about:

    • The system on which the development runs, windows, linux, mac or whether it is system independent.
    • The hardware architecture.
    • The minimum version of the java virtual machine required.

    These could be one of the following:

    • all-all-j1_5, for binaries compiled for Java Virtual Machine version 1.5.x that are independent of the system and hardware architecture.
    • all-all-j1_6, for binaries compiled for Java Virtual Machine version 1.6.x that are independent of the system and hardware architecture.
    • win-i586-j1_5, for MS Windows binaries compiled for Java Virtual Machine version 1.5.x.
    • win-i586-j1_6, for MS Windows binaries compiled for Java Virtual Machine version 1.6.x.
    • lin-i586-j1_5, for linux binaries compiled for Java Virtual Machine version 1.5.x.
    • lin-i586-j1_6, for linux binaries compiled for Java Virtual Machine version 1.6.x.
    • mac_10_4-i586-j1_5, for Mac OS version 10.4 binaries compiled for the Java Virtual Machine that includes the base for that version of Mac (java 1.5).

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.

  • With respect to extensions, the following are used:
    • exe for MS Windows installables.
    • bin for Linux installables.
    • zip for Mac installables and multi-platform versions.

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:

  • man-version is the version number of the manual. It is possible that multiple versions of the manual might be generated for a specific version of the product. Normally the version of the manual that is made available at the product's initial distribution is enhanced during the following weeks or months. Updated versions of the manual are then published without recreating a new distribution of the application.
  • lang-code identifies the language the manual is written in. ISO639 Alpha-2 code space codes should be used for these wherever possible.

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:

  • Firstly, the bug must be recorded in the gvSIG bug registry. gvSIG uses as a bug registry a tracker into the issues manager.

    To record the bug, it is advisable to register as a user of the forge, but if you do not register you still can record it.

    It is advisable to read the following documentation before loading a bug into the registry:

    Once the bug is recorded, you could attach to it a patch with the source code and mark the field Has patch with a yes in the ticket.

    Tip

    It is very important to mark in the ticket since the Patch field is used by the development team to identify bugs that contribute code.

    The more information is provided in the ticket description about what your code does, more ease will be the task of the gvSIG person responsible for assessing the potential impact of its correction.

    If after evaluating the correction of the bug it is considered appropriate to place it in gvSIG, you will be advised through your ticket that the task has been performed.

    If this correction is considered to be problematic, you will also be informed through your ticket.

  • On the other hand, 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.

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:

  • What is the new feature to be added to gvSIG? It is not the feature that you want to implement in your plugin, but the one you need to add to gvSIG in order to develop your plugin.
  • The motivation that led you to seek the introduction of this feature, what do you need it for?.
  • How you plan to address it. A written account of how you will implement the feature, which modules need to be changed, why and what for?
  • A written account of what parts of gvSIG you think may be affected by the proposed changes.

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:

  • If your request involves changes in various parts of the application it may require the intervention of several developers for testing. This may slow down the process of inclusion of the amendments.
  • If it is found that your request may result in loss compatibility or data with user projects, you should review your proposal, because it will not be accepted.
  • An inadequate documentation of the new feature may cause not be understood by those responsible with its evaluation, with the consequent rejection. Provide all information you deem relevant to facilitate the task of evaluating your proposal.
  • Your request can be considered irrelevant since there might be already other ways to do it. Consult with development lists before you begin making changes in gvSIG.

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
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:

  • External developer
  • Project developer
  • Maintainer
  • Reviewer
  • Tester
  • Software architecture support
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:

  • What must a for inclusion in the Distribution gvSIG enforcement officer. Package supplied will be included in the web repository of packages gvSIG it need not be distributed with the binaries the official release.

  • What must a to be considered a project gvSIG official. You can find documentation on the document gvSIG official projects

  • Modifications or contributions to existing code in gvSIG.

    If you want to contribute code to an existing project in gvSIG see Contributions and patches to the gvSIG code.

  • Como solicitar al proyecto que albergue nuestro paquete. El responsable y creador del paquete deberá alojarlo en un servidor publico con acceso a el por http, entregando al proyecto solo el archivo gvspki con los metadatos del paquete.

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:

  • To be released under GPL 2 or compatible license.
  • You can not replace files out of plugin folder being installed. If it is necessary to be communicated and assess this need.
  • Information should be provided on the code and version package.
  • You must provide the name and description of the package in English.
  • You must provide the name of the owner.
  • You must supply the URL that allows access to the source from which it was generated.
  • They must be correctly filled all the packet data package.info the file.
  • It will be advisable to follow the package name nomenclature generated by the plugin package tool provided in gvSIG facilities. If not, be justified.

In addition to these requirements is highly recommended:

  • The existence of associated user documentation for functionality provided by the package. This documentation must be freed with Creative Commons .
  • That there is a tracker to report bugs in the creators of this.

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.

  • Update the contents of a package without increasing the number of version or build.

    Each time you change the plugin, you must generate a new package reflecting that at least the increasing number of build, sending back to the project gvspki the file. If detected from the project has changed the package keeping the same version number and build, will retire on package repository.

  • If from the gvSIG team are consulted through the comments to the ticket which apply for registration packet that are not answered, you can remove the package from the repository or not enter the if you have not been done.

  • If it is found that the use of the functionality provided by the package can cause loss of data by the user of these, this may be removed from the package repository.

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:

  • Add-on name must indicate the name of the package on which want to make the request.
  • Add-on code. In case it is a new packet and not in a list of packages add-on name, you must indicate here Package code to add.
  • Add-on operation requested. You must indicate the type of operation that applying.
  • Subject short description of what you want done.
  • Description. Indicate here the url to the file gvspki of your package. You enter the information that it considers may be of interest to facilitate the acceptance of the package, as well as inclusion in the package repository.

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.

Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: