VSD-Project > Governance

Governance for the Maintenance and Distribution of the VSD Software

Access principles

Data from the VSD project is distributed on vsd.esa.int (the site) with 3 basic levels of access:

Public Access (Anonymous)

This is the data which is visible on the site for anyone. No user registration is required to access that data. Its content is general information and marketing material.

VSEE User Access (VSEE-User)

In order to be able to download any VSD related software, interesting parties need to

The default access level (VSEE-User) provides access to

  1. VSD Binary Software Installers
  2. User Manuals
  3. Support Issue Tracker (SIT), i.e. report issues with the software

For details, see the detailed access matrix.

VSEE Developer Access (VSEE-Developer)

Access to the VSEE Source code is granted upon specific request either in the contact form or by email for existing accounts. For any kind of contributions to the VSEE source code, developers can also request access to the VSEE SVN Repository and gain commit rights to that repository. For any kind of contributions to the VSEE source code, developers can request access to the VSEE SVN Repository and gain commit rights to that repository.

Additional Levels of access

The following additional access levels are maintained on a technical level:

Partner/Author access (Author)

This is a role which allows certain parties such as the VSD consortium to modify content on the site (e.g. information pages on specific areas, etc.)

Admin access (Administrator)

This is the admin role which is primarily used by the VSD maintainer. It also has the capability to access and modify Change Tickets.

User registration, licensing and vetting

Registration

In order to access any non-public data on the site, users need to register by providing the following information on this page.

After accepting the ESA SOFTWARE COMMUNITY LICENSE – TYPE 2 – V1.0  and submitting the form, the designated ESA contact will be notified by automated email.

License

See VSD Licenses.

User vetting

The designated ESA contact will confirm that the requestor is in fact a legal person in one of the member states of ESA” (according to “territory” as defined in 1.13 of the ESA SOFTWARE COMMUNITY LICENSE – TYPE 2 – V1.0)

Upon successful vetting, the designated ESA contact will create a site user for the requestor, the requestor will get an automated email with username and password. The default role of a newly created user account will be VSEE-User.

Once this access has been granted, additional links and downloads (i.e. Installers, Metamodel Wiki as defined in Detailed access matrix) will be available to the user.

Developer access

Normal site registration and successful vetting does not include access to the VSEE source code or the VSEE SVN source code repository. Developer access should either be requested in the contact form or should be requested by email for an existing account.

Once this access has been granted (i.e. the user’s role has been changed to VSEE-Developer), users can commit modified source code to the VSEE SVN source code repository.

Login and access

Using the provided account name and password, the requestor can then login to the site and access additional data as determined by the respective role.

Feedback and Issue tracking process

The site provides basically 2 separate feedback channels:

General feedback and questions

For general questions and discussion, any vetted user can submit topic in the site’s discussion forums. These forums are monitored by the designated ESA contact and support staff, questions are answered as time permits. The forum is not moderated.

Non-registered site visitors can read the forum contents.

Detailed issues, feature requests and bugs

More detailed issues, like specific feature requests or bug reports can be submitted through a dedicated issue tracking system. Any issues logged through that system will get evaluated and potentially scheduled by the quarterly Change Control Board (CCB). The CCB consists of the designated ESA contact plus support staff, in case the CCB accepts a feature or bug issue, the corresponding ticket will be scheduled for an upcoming VSD release accordingly.

Submitters of tickets will be notified by automated email on any status changes.

Support Issues Tracker (SIT)

This is the basic “incoming” tracker, i.e. any user of the VSD S/W can log questions, defects (i.e. SPRs), feature requests and proposed contributions in it. The tracker shall classify the tickets accordingly (i.e. SPR, FeatureRequest, FeatureContribution, etc.)

Access: VSEE-User read/write

Change Tracker (CT)

This is the tracker which holds all S/W changes which will or have been actually implemented in subsequent VSD S/W releases. Tangible outputs of the CCB will be the transformation and scheduling of STTs into CTTs. The Change tracker will also include config management classification (i.e. schedule CTTs for a particular VSD S/W release)

Access: Administrator read/write

Decision criteria for the scheduling of change requests

The following criteria will apply to the decision process which schedules or defers any change requests or contributions:

  • Cost and Level of Effort
  • General interest to the user community

Decisions taken by the CCB are manifested by the respective transformation and scheduling of Support Issue Tickets into Change Tickets. Change Tickets for a given release are finally transformed into Release-Notes for that release.

Contribution process

VSD software users are generally encouraged to submit any changes they make to the software back to the community. In any case, any further distribution of changes to the code has to be made according to the same license terms as originally distributed.

In general, the following two types of contributions are foreseen:

Modifications of VSD source code

Any such work i.e. modifications, improvements, etc. considered to be “internal” to the initial VSEE SW are regulated by the “Type 2 License” (see Appendix B). This license basically mandates that any such work shall be licensed by the same license as the original software (i.e. by the Type 2 License).

Integrations of 3rd-party tools into VSEE

Such integrations will typically use and rely on the VSEE datacore source (which is bundled and available separately) but will not change the existing VSEE source code. This kind of usage is governed by the “Type 3 License”. This license basically regulates that any derivative work needs to reference

  • The VSD credits and acknowledgments
  • The original license (i.e. Type 3)

This work may however follow any license, including proprietary licenses. In other words, 3rd-party integrations to VSEE software can be built and released without having to license this integration under the ESA SOFTWARE COMMUNITY LICENSE – TYPE 2, i.e. there is no Copyleft in this case.

Contribution logistics

Depending on the nature of the contribution and the decisions made by the CCB for that change, the contribution shall either be provided through a ZIP archive containing the respective source code or the respective user will get commit rights to the VSD source code repository.

In either case, any contribution will be committed by the VSD maintainer to a dedicated branch in the VSD source code repository form where it will be built and tested.

As stated above, in case of integrations to VSEE, the EMF based VSEE DataCore can be reused. In order to simplify the setup of such a development environment, an Eclipse workspace with the DataCore source is available. For integration only work, this workspace is recommended because it has much less dependencies on other Eclipse plugins as compared to the full VSEE source code.

Comments are closed.