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

From GRASS-Wiki
Jump to navigation Jump to search
Line 3: Line 3:
== Decisions made ==
== Decisions made ==


* Startup: New GUI startup procedure and roadmap for implementing it
* 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.
** 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.
* GitHub migration: Keep current tickets on track open, but open new issues on GitHub.
* 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.
** 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.
** Open new issues on GitHub and direct all users there.
Line 11: Line 11:
** No migration of issues to GitHub is needed which makes this plan simple to execute.
** 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.
** 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 ==
== Vaclav Petras ==

Revision as of 10:20, 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)