Difference between revisions of "Talk:GRASS GIS Community Sprint Prague 2019"

From GRASS-Wiki
Jump to navigation Jump to search
(update Ondrej Pesek)
Line 43: Line 43:
== Ondrej Pesek ==
== Ondrej Pesek ==

* https://github.com/OSGeo/grass/pull/231
* README refactoring: https://github.com/OSGeo/grass/pull/231
* https://github.com/OSGeo/grass/pull/234
* bug fixing
* https://github.com/OSGeo/grass/pull/241
** https://github.com/OSGeo/grass/pull/234
** https://github.com/OSGeo/grass/pull/241
* Updating artificial neural network modules docs to correspond with GRASS 7.8 (see [https://github.com/OSGeo/grass-addons/compare/master@%7B12/02/2019%7D...master@%7B12/07/2019%7D github commits] overview)
* Working on g.gui.gmodeler PyWPS export (see [https://github.com/ctu-yfsg/2017-d-grass-modeler-pywps/compare/master@%7B12/01/2019%7D...master@%7B12/07/2019%7D github commits] overview)

== Markus Neteler (remote) ==
== Markus Neteler (remote) ==

Revision as of 12:30, 6 December 2019

Participants and Reports

Decisions made

  • 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.

Also discussed

  • 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.

Vaclav Petras

Martin Landa


Anna Petrasova

Ondrej Pesek

Markus Neteler (remote)