Talk:GRASS GIS Community Sprint Prague 2019
Jump to navigation Jump to search
Participants and Reports
- New startup: New GUI startup procedure and roadmap for implementing it
- We spent several hours over the course of the sprint discussing different alternatives and finding a best way to implement the one we have chosen.
- Migration to GitHub: Keep current tickets on track open, but open new issues on GitHub.
- Keep current tickets on track open (i.e., valid and to be used), but disable opening new tickets. People involved in old tickets can continue discussing there.
- Open new issues on GitHub and direct all users there.
- We just need to clarify on mailing list that if you opened or are following an issue on Trac, you should continue there.
- No migration of issues to GitHub is needed which makes this plan simple to execute.
- Everybody is encouraged to be more "aggressive" about closing old tickets on Trac which are now invalid or no longer relevant. Opening new updated issue after that on GitHub is welcome.
- Windows builds:
- In the long run, we need CMake build with subsequent MSVC (Microsoft Visual C++) compatibility changes for smooth CI/CD builds on Windows and easier packaging on Windows.
- We need to test Azure Pipelines for Linux build (needed for both Windows and conda-forge builds).
- conda-forge packaging is need as an alternative (other related projects are already using it, current macOS builds are already based on Conda packages).
- Standalone Windows installer should include Jupyter (Jupyter Notebooks and/or JupyterLab).
- Python scripting: Python API needs to be consolidated before 8.0.
- The pygrass naming needs to be resolved.
- Current grass.pygrass.modules need to be strictly separated from ctypes dependencies.
- The duplication between run_command() family and grass.pygrass.modules needs to be resolved.
- The concept of running in different sessions needs to be explicitly supported and expressed in API.
- Use response to an unknown method call (__getattr__()) in implementation of a session object which then (in __getattr__()) passes the right env to the called function.
- This applies not only to module call wrappers, but to all functions which call modules in the background.
- ctypes-based API probably always need to use the current session.
- Temporal libraries are unclear.
- Release terminology: Perhaps we should call releases just releases, not adding "stable" like now. After couple of minor versions (when the branch is widely tested), the specific minor release and subsequent minor releases would be called stable. For example, 7.8.0, 7.8.1, and 7.8.2 would be simply releases while 7.8.3 would be marked stable and each subsequent release such as 7.8.4 and 7.8.5 would be stable release as well.
- Creating notes for New Startup discussion (https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup#GRASSGISCommunitySprintPrague2019)
- New Startup Roadmap: https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup#PragueRoadmap
- Testing CMake build of GRASS GIS by rkanavath (https://github.com/rkanavath/grass-ci)
- PR for CONTRIBTING file (https://github.com/OSGeo/grass/pull/237)
- Update Trac wiki Submitting/General (https://trac.osgeo.org/grass/wiki/Submitting/General?action=diff&version=17)
- PR for sync keywords of r.null & comp. (https://github.com/OSGeo/grass/pull/239)
- Notes on *Decisions made* here
- update wxPython OSGeo4W package to 4.0.7, https://trac.osgeo.org/osgeo4w/ticket/615
- GRASS 7.8.2RC1 UbuntuGIS Expr package published
- bug fixing
- r.sim improvements - dynamic allocation
- README refactoring: https://github.com/OSGeo/grass/pull/231
- bug fixing
- Updating artificial neural network modules docs to correspond with GRASS 7.8 (see github commits overview)
- Working on g.gui.gmodeler PyWPS export (see github commits overview)