January meeting 2017

The PSC gathered to discuss the following agenda:

• What should be the practical development process for Oskari and what is the role of the PSC in this.
• Requirements for pull requests
• Who can do a review for a pull request.
• What kind of code is accepted to the Oskari-repository and what should be cleaned out of it.
• How to handle bigger UI changes (and how to decide what is big UI change) on the application components.
• Do we need namespaces on the bundles or can we flatten the directory structure?
• Naming of Oskari classes, events, requests etc in future development
• Other coding style decisions like get/set change in the core.
• Roadmap issues.
• Other issues

Opening the meeting

Attendees:

• Sami Mäkinen
• Jaakko Ruutiainen
• Tuuli Pihlajamaa
• Jussi Arpalahti
• Tomi Lukkarinen
• Marko Kauppi
• Timo Sallinen

Via conference call:

• Heikki Ylitalo
• Marko Kuosmanen

Not present:

• Hafliði Sigtryggur Magnússon

Development process

The development process and code flow was discussed from practical point-of-view. Customization being done on top of Oskari usually have a tight schedule and developers can’t be expected to wait for pull requests to be accepted before moving on with the development of a feature.

Developers need to fork the Oskari-repository that require changes and continue working on the feature while submitting pull requests. There are also cases where multiple developers from different companies are implementing features on top of Oskari to be used in a customized Oskari-instance. These changes might need to go live on that instance before the code is merged to the official Oskari-repository. In these cases the organization with the customized Oskari-instance should have their own fork of the Oskari-repositories. Pull requests that have been sent to Oskari-repositories can then be merged to the customized fork even before they are accepted to the official repository.

Oskari Improvement Proposal (OIP)

We need to provide practical instructions how to contribute. Like when you start working on new functionality:

• make plans of functionalities for the PSC to approve
• evaluate whether a new bundle is needed
• evaluate if there are requirements for existing code to provide hooks for the new functionality?

Challenges:

• client paying for the change may want to alter requirements after OIP has been submitted
• When is an OIP required instead of a simple pull request?

Requirements for pull requests

Discussed about automated tests, the need for implementing a base for front-end testing that can be extended, test coverage requirements and Travis CI for automatically checking pull requests against test-suites. We need a checklist for doing the reviews.

No decisions were made yet.

Who can do a review for a pull request

It was agreed that not everyone in the PSC is able to review code changes/pull requests so this should not be limited to members of the PSC.

On further discussion it was agreed that the GeoServer-project has documented their approach on these issues and we could use the same practical approach:

• Commits
• Pull requests
• Reviews

We also discussed that we should work on increasing the number of developers with core commit access to keep a review queue from building up.

What kind of code is accepted to the Oskari-repository and what should be cleaned out of it.

Sami introduced changes for the new release with sources-folder being removed and the actual Oskari-core now included in the src-folder. The core offers the basic framework to run actual functionalities that are located in the bundles-folder.

It was decided that the current frontend-repository should be cleaned up. Any application-specific functionalities should be moved to a new community-repository (naming still under consideration). The code that remains in the Oskari-repository needs to have a responsible party for maintaining the functionality and everything in the repository should be documented (usage, configuration etc) and working with the latest Oskari version. If a bundle is no longer maintained and no-one else claims responsibility it will be moved to the community-repository. Commit access to the Oskari-repository could be granted by gaining the trust of the previous core committers (similar to the GeoServer-project).

The community-repository could have more relaxed requirements. Commit access could be granted for anyone working with Oskari and the functionality bundles are not expected to work on the latest Oskari version. These bundles need to declare the last known version of Oskari they have been used with.

Sami will make a suggestion what bundles are to be moved out of the Oskari-repository and provide an example how to use the community-bundles in an Oskari-application.

How to handle UI changes

This is related to the requirements of pull requests and needs to be discussed further.

No decisions were made.

Do we need namespaces on the bundles

Cleaning up the Oskari-repository will make this decision easier.

No decisions were made yet.

Naming of Oskari classes, events, requests etc in future development

Naming of functions, events and requests was discussed. Sami introduced a new style for get/set-functions in the core with:

// get value
value()
//set value
value(10)

A decision is required whether we should use this way or separate functions as coding style.

Another issue is the naming of events and requests. There’s currently no rules on the naming with some of the names including reference to the bundle that offers them and some not. Also the reference is not the actual bundle id, but some variation of it. Challenge in this is that old events/requests cannot be renamed without backwards compatibility as it breaks a lot of features/RPC-enabled applications. An example for new naming scheme was introduced here: https://github.com/nls-oskari/oskari/blob/develop/bundles/mapping/mapmodule/event/map.layer.activation.js

No decision was made yet, but it was agreed that the code should be consistent. Discussion will be continued in Slack.

Roadmap(/GitHub) issues

Discussed challenges of choosing roadmap issues based on very limited information.

Labels

Labels are used to separate issues between bugs, enhancements/wishlist, roadmap and OIPs:

• Bug labeled issues should be described with helpful information like Oskari version, browser information and/or steps to reproduce.
• Roadmap label is used for issues that don’t have detailed plans, but have funding/real commitment from a contributor/organization. Roadmap issue can have very short description about a planned feature with information about the committed party.
• Enhancement label is used for issues that would be nice, but no-one is currently committed on making it happen. Kind of a “wishlist”.
• OIP label is used for Oskari improvement proposals. The content should be detailed with template provided on the GitHub-wiki.
• Documentation label is used for issues concerning the support site (oskari.org).

Roadmap listing

Having the roadmap items listed on http://oskari.org was discussed. This could be done using the GitHub API. A documentation issue was added to GitHub and Jussi agreed to take a look at this.

Progress tracking

Tracking the progress of issues on the repository was discussed. The PSC agreed on using the Waffle.io service for this purpose as it’s lightweight and only manages the labels of issues so it’s easily replaceable. Sami will take a look at this.

Contributor permissions will be added to PSC members for github.com/nls-oskari/oskari.org -repository. Sami will take care of this.

Other issues

GitHub repository naming

Concerns have been raised about having nls in the name of the GitHub account for Oskari. The PSC agreed on moving the repositories under different account/GitHub-organization.

After further discussion https://github.com/oskariorg was reserved for the new name. Repository move needs to be coordinated and possibly have the current repository urls preserved with a note about the new location. Links in the OSGeo incubation application and all over oskari.org need to be updated.

Oskari-showcase

http://demo.oskari.org is the showcase site for Oskari. It should have the latest released version of Oskari and showcase all the supported functionality. A gallery-style frontpage should be implemented so the user can select to see different kind of appsetups implemented with Oskari. This way we don’t need to use every supported bundle in one sample-application. A development environment is also required for testing changes and pull requests.

Sami will investigate what it would mean to setup dev.oskari.org (possibly on the same server as demo.oskari.org).

Things to consider

Do we want to keep feature branches in the public repository? Do we want save branch history? Do we rebase pull requests? Branches might show which code was related to which feature at the time they are done, but propably don’t offer much after some time has passed. Git blame might be better suited for this kind of forensics. Homework for everyone: familiarize with GitFlow documentation. Discussions on the matter will be continued on Slack. No decisions were made on these.

Future meetings

Agreed on not having regular meeting schedule, but having meetings when required. Most of the work can propably be done online.