The PSC gathered to discuss the following agenda:
Via conference call:
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.
We need to provide practical instructions how to contribute. Like when you start working on new functionality:
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.
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:
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.
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.
This is related to the requirements of pull requests and needs to be discussed further.
No decisions were made.
Cleaning up the Oskari-repository will make this decision easier.
No decisions were made yet.
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.
Discussed challenges of choosing roadmap issues based on very limited information.
Labels are used to separate issues between bugs, enhancements/wishlist, roadmap and OIPs:
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.
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.
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.
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).
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.
Agreed on not having regular meeting schedule, but having meetings when required. Most of the work can propably be done online.