[Git][debian-gis-team/grass][experimental] 4 commits: New upstream version 8.4.0

Bas Couwenberg (@sebastic) gitlab at salsa.debian.org
Sat Jul 27 17:34:52 BST 2024



Bas Couwenberg pushed to branch experimental at Debian GIS Project / grass


Commits:
250d661b by Bas Couwenberg at 2024-07-27T18:15:40+02:00
New upstream version 8.4.0
- - - - -
fc856f0d by Bas Couwenberg at 2024-07-27T18:18:36+02:00
Update upstream source from tag 'upstream/8.4.0'

Update to upstream version '8.4.0'
with Debian dir 77ef87bd053f855df793a89aa213cfac6445d610
- - - - -
90a5d4b1 by Bas Couwenberg at 2024-07-27T18:21:02+02:00
New upstream release.

- - - - -
ff425b77 by Bas Couwenberg at 2024-07-27T18:22:44+02:00
Set distribution to experimental.

- - - - -


17 changed files:

- CONTRIBUTING.md
- debian/changelog
- + doc/development/github_guide.md
- − doc/help_loc_structure.odg
- + doc/help_project_structure.odg
- doc/howto_release.md
- grasslib.dox
- gui/wxpython/gmodeler/dialogs.py
- gui/wxpython/gmodeler/panels.py
- include/VERSION
- lib/init/Makefile
- − lib/init/help_loc_struct.png
- + lib/init/help_project_structure.png
- − lib/loc_struct.png
- raster/r.in.pdal/info.cpp
- raster/r.li/r.li.html
- utils/generate_release_notes.py


Changes:

=====================================
CONTRIBUTING.md
=====================================
@@ -8,122 +8,13 @@ or explore <https://grass.osgeo.org/get-involved/>.
 
 ## Changing code and documentation
 
-This guide covers contributing to the main version of GRASS GIS source
-code which is in the branch called _main_.
-It assumes that you have some very basic knowledge of Git and GitHub,
-but if you don't just go through some tutorial online or ask on the
-GRASS GIS developer mailing list.
+To contribute changes to GRASS GitHub repository, use a
+"fork and pull request" workflow. This [guide](./doc/development/github_guide.md)
+leads you through a first time setup and shows how to create a pull request.
 
 To contribute effectively, please familiarize yourself with our
 [Programming Style Guide](./doc/development/style_guide.md).
 
-### First time setup
-
-* Create an account on GitHub.
-* Install Git on your computer.
-* Set up Git with your name and email.
-* Fork the repository (by clicking the `Fork` button in the upper right corner
-  of the GitHub interface).
-* Clone your fork (use HTTPS or SSH URL, here we will use HTTPS):
-
-```bash
-git clone git at github.com:your_GH_account/grass.git
-```
-
-* Enter the directory
-
-```bash
-cd grass/
-```
-
-* Add main GRASS GIS repository as "upstream" (use HTTPS URL):
-
-```bash
-git remote add upstream https://github.com/OSGeo/grass
-```
-
-* Your remotes now should be "origin" which is your fork and "upstream" which
-  is this main GRASS GIS repository. You can confirm that using:
-
-```bash
-git remote -v
-```
-
-* You should see something like:
-
-```bash
-origin  git at github.com:your_GH_account/grass.git (fetch)
-origin  git at github.com:your_GH_account/grass.git (push)
-```
-
-For the following workflow, it is important that
-"upstream" points to the OSGeo/grass repository
-and "origin" to your fork
-(although generally, the naming is up to you).
-
-### Update before creating a feature branch
-
-* Make sure your are using the _main_ branch to create the new branch:
-
-```bash
-git checkout main
-```
-
-* Download updates from all branches from the _upstream_ remote:
-
-```bash
-git fetch upstream
-```
-
-* Update your local _main_ branch to match the _main_ branch
-  in the _upstream_ repository:
-
-```bash
-git rebase upstream/main
-```
-
-Notably, you should not make commits to your local main branch,
-so the above is then just a simple update (and no actual
-rebase or merge happens).
-
-### Update if you have local changes
-
-If `rebase` fails with "error: cannot rebase: You have unstaged changes...",
-then move your uncommitted local changes to "stash" using:
-
-```bash
-git stash
-```
-
-* Now you can rebase:
-
-```bash
-git rebase upstream/main
-```
-
-* Get the changes back from stash:
-
-```bash
-git stash pop
-```
-
-### Creating a new feature branch
-
-Now you have updated your local _main_ branch, you can create a feature branch
-based on it.
-
-* Create a new feature branch and switch to it:
-
-```bash
-git checkout -b new-feature
-```
-
-### Making changes
-
-You can use your favorite tools to change source code or other files
-in the local copy of the code. When making changes, please follow the
-[Programming Style Guide](./doc/development/style_guide.md).
-
 ### Testing changes
 
 Testing helps to ensure that the changes work well with the rest
@@ -145,57 +36,6 @@ For Python, run `black .` to apply standardized formatting. You can
 also run linter tools such as Pylint which will suggest different improvements
 to your code.
 
-### Committing
-
-* Add files to the commit (changed ones or new ones):
-
-```bash
-git add file1
-git add file2
-```
-
-* Commit the change (first word is the module name):
-
-```bash
-git commit -m "module: added a new feature"
-```
-
-### Pushing changes to GitHub
-
-* Push your local feature branch to your fork:
-
-```bash
-git push origin new-feature
-```
-
-### Pull request
-
-When you push, GitHub will respond back in the command line to tell
-you what URL to use to create a pull request. You can follow that URL
-or you can go any time later to your fork on GitHub, display the
-branch `new-feature`, and GitHub will show you a button to create
-a pull request.
-
-Alternatively, you can explore GitHub CLI tool (_gh_) which allows you
-to do `git push` and create a pull request in one step with `gh pr create -fw`.
-
-### After creating a pull request
-
-GRASS GIS maintainers will now review your pull request.
-If needed, the maintainers will work with you to improve your changes.
-
-Once the changes in the pull request are ready to be accepted,
-the maintainers will usually squash all your commits into one commit and merge it
-to the _main_ branch.
-
-Once the pull request is merged, it is a good time to update your
-local _main_ branch in order to get the change you just contributed.
-
-### Further notes
-
-GRASS GIS maintainers use additional workflows besides the one described
-above. These are detailed at <https://trac.osgeo.org/grass/wiki/HowToGit>
-
 ## Compilation
 
 More often than not, in order to test the changes, you need to create


=====================================
debian/changelog
=====================================
@@ -1,3 +1,9 @@
+grass (8.4.0-1~exp1) experimental; urgency=medium
+
+  * New upstream release.
+
+ -- Bas Couwenberg <sebastic at debian.org>  Sat, 27 Jul 2024 18:22:27 +0200
+
 grass (8.4.0~rc1-1~exp1) experimental; urgency=medium
 
   * New upstream release candidate.


=====================================
doc/development/github_guide.md
=====================================
@@ -0,0 +1,187 @@
+# Guide to contributing on GitHub
+
+This guide covers contributing to the GRASS GIS source,
+specifically to the _main_ branch.
+It assumes that you have some very basic knowledge of Git and GitHub.
+
+## First time setup
+
+1. Create an account on GitHub.
+1. Install Git on your computer.
+1. Set up Git with your name and email.
+1. Fork the repository (by clicking the `Fork` button in the upper right corner
+  of the GitHub interface).
+1. Clone your fork (use HTTPS or SSH URL, here we will use HTTPS):
+
+```bash
+git clone https://github.com/your_GH_account/grass.git
+```
+
+1. Enter the directory:
+
+```bash
+cd grass/
+```
+
+1. Add the main GRASS GIS repository as "upstream" (use HTTPS URL):
+
+```bash
+git remote add upstream https://github.com/OSGeo/grass
+```
+
+1. Your remotes now should be "origin" which is your fork and "upstream" which
+  is this main GRASS GIS repository. You can confirm that using:
+
+```bash
+git remote -v
+```
+
+1. You should see something like:
+
+```bash
+origin  https://github.com/your_GH_account/grass.git (fetch)
+origin  https://github.com/your_GH_account/grass.git (push)
+upstream  https://github.com/OSGeo/grass (fetch)
+upstream  https://github.com/OSGeo/grass (push)
+
+```
+
+For the following workflow, it is important that
+"upstream" points to the OSGeo/grass repository
+and "origin" to your fork
+(although generally, the naming is up to you).
+
+## Update before creating a feature branch
+
+Make sure your are using the _main_ branch to create the new branch:
+
+```bash
+git checkout main
+```
+
+Download updates from all branches from the _upstream_ remote:
+
+```bash
+git fetch upstream
+```
+
+Update your local _main_ branch to match the _main_ branch
+  in the _upstream_ repository:
+
+```bash
+git rebase upstream/main
+```
+
+Notably, you should not make commits to your local main branch,
+so the above is then just a simple update (and no actual
+rebase or merge happens).
+
+## Creating a new feature branch
+
+Now you have updated your local _main_ branch, you can create a feature branch
+based on it.
+
+Create a new feature branch and switch to it:
+
+```bash
+git switch -c new-feature
+```
+
+## Committing
+
+Add files to the commit (changed ones or new ones):
+
+```bash
+git add file1
+git add file2
+```
+
+Commit the change. Write a meaningful commit message (first word is for example
+the tool name):
+
+```bash
+git commit -m "tool: added a new feature doing X"
+```
+
+## Pushing changes to GitHub
+
+Push your local feature branch to your fork:
+
+```bash
+git push origin new-feature
+```
+
+## Creating a pull request
+
+When you push, GitHub will respond back in the command line to tell
+you what URL to use to create a pull request (PR). You can follow that URL
+or you can go any time later to your fork on GitHub, display the
+branch `new-feature`, and GitHub will show you a button to create
+a PR.
+
+Alternatively, you can explore GitHub CLI tool (_gh_) which allows you
+to do `git push` and create a PR in one step with `gh pr create -fw`.
+
+## After creating a PR
+
+GRASS GIS maintainers will now review your PR.
+If needed, the maintainers will work with you to improve your changes.
+
+Once the changes in the PR are ready to be accepted,
+the maintainers will usually squash all your commits into one commit and merge it
+to the _main_ branch.
+
+Once the PR is merged, it is a good time to [update your
+local _main_ branch](#update-before-creating-a-feature-branch) in order to get
+the change you just contributed.
+
+## Further notes
+
+Here we cover common situations and how to deal with them:
+
+### Update if you have local changes
+
+Assumption is you are on the main branch and you are trying to update it.
+If `git rebase` fails with `error: cannot rebase: You have unstaged changes...`,
+then move your uncommitted local changes to "stash" using:
+
+```bash
+git stash
+```
+
+Now you can rebase:
+
+```bash
+git rebase upstream/main
+```
+
+Get the changes back from stash:
+
+```bash
+git stash pop
+```
+
+### Updating your PR from main
+
+Updating your PR from the main branch is often referred to as rebasing a PR.
+It comes into play in case there are changes in the main branch you need to
+incorporate into your (feature or fix) branch before the PR can be merged,
+you need to merge the upstream main into your branch:
+
+```bash
+git fetch upstream
+git merge upstream/main
+```
+
+Git will ask you to edit the merge commit messsage, you can leave the default
+and close the editor. You may run into a conflict,
+in that case you need to resolve it.
+
+### Testing PRs from other contributors
+
+For testing other contributors' PRs, we recommend using
+[GitHub CLI](https://cli.github.com/). To checkout a specific PR, run:
+
+```bash
+gh pr checkout <PR number>
+```


=====================================
doc/help_loc_structure.odg deleted
=====================================
Binary files a/doc/help_loc_structure.odg and /dev/null differ


=====================================
doc/help_project_structure.odg
=====================================
Binary files /dev/null and b/doc/help_project_structure.odg differ


=====================================
doc/howto_release.md
=====================================
@@ -133,7 +133,7 @@ see: <https://help.github.com/en/articles/creating-releases>.
 ### Tag release
 
 Before creating the tag, it is a good idea to see if the CI jobs are not failing.
-Check on GitHub or use GitHub CLI:
+Check on [GitHub Actions](https://github.com/OSGeo/grass/actions) or use GitHub CLI:
 
 ```bash
 gh run list --branch releasebranch_8_4
@@ -152,7 +152,7 @@ stored for annotated tags including a date; message is suggested by the
 `./utils/update_version.py` script):
 
 ```bash
-git tag $TAG -a -m "..."
+git tag $TAG -a -m "GRASS GIS $VERSION"
 ```
 
 List all tags (annotated will be at the top of both lists):
@@ -174,15 +174,15 @@ so that you can continue in the release process.
 
 ### Create release notes
 
-Generate a draft of release notes using a script. The script the script needs to
+Generate a draft of release notes using a script. The script needs to be
 run from the top directory and will expect its configuration files
 to be in the _utils_ directory.
 
-#### Major and minor releases
+#### First RC of a major and minor releases
 
-For major (X.y.z) and minor (x.Y.z) releases, GitHub API gives good results for the
-first release candidate because it contains contributor handles and can identify
-new contributors, so use with the _api_ backend, e.g.:
+For a first RC of a major (X.y.z) and minor (x.Y.z) release, the GitHub API gives
+good results for the first release candidate because it contains contributor handles
+and can identify new contributors, so use with the _api_ backend, e.g.:
 
 ```bash
 python ./utils/generate_release_notes.py api releasebranch_8_4 8.3.0 $VERSION
@@ -198,7 +198,7 @@ The _git log_ command operates on commits, so use use the _log_ backend:
 python ./utils/generate_release_notes.py log releasebranch_8_4 8.4.0 $VERSION
 ```
 
-#### RCs
+#### Between RCs and from last RC to final release
 
 In between RCs and between last RC and final release, the _log_ backend is useful
 for showing updates since the last RC:
@@ -214,7 +214,7 @@ added manually to the result from the _api_ backend.
 
 The script sorts them into categories defined in _utils/release.yml_.
 However, these notes need to be manually edited to collapse related items into
-one. Additionally, a _Highlights_ section needs to be added with manually
+one. Additionally, a _Highlights_ section needs to be added on top with manually
 identified new major features for major and minor releases. For all releases, a
 _Major_ section may need to be added showing critical fixes or breaking changes
 if there are any.
@@ -260,7 +260,8 @@ Eventually, commit with the suggested commit message and push, e.g.:
 
 ```bash
 git show
-git commit include/VERSION -m "..."
+eval $(./utils/update_version.py status --bash)
+git commit include/VERSION -m "version: Back to $VERSION"
 git push upstream
 ```
 
@@ -349,11 +350,14 @@ SERVER2=osgeo7-download
 SERVER2DIR=/osgeo/download/grass/grass$MAJOR$MINOR/source/
 echo $SERVER1:$SERVER1DIR
 echo $SERVER2:$SERVER2DIR
+eval $(ssh-agent) && ssh-add
 
-# upload along with associated files:
+# upload along with associated files, creating target dir if still needed
+ssh $USER@$SERVER1 "mkdir -p $SERVER1DIR"
 scp -p grass-$VERSION.* AUTHORS COPYING ChangeLog_$VERSION.gz \
   INSTALL.md REQUIREMENTS.md CONTRIBUTING.md $USER@$SERVER1:$SERVER1DIR
 
+ssh $USER@$SERVER2 "mkdir -p $SERVER2DIR"
 scp -p grass-$VERSION.* AUTHORS COPYING ChangeLog_$VERSION.gz \
   INSTALL.md REQUIREMENTS.md CONTRIBUTING.md $USER@$SERVER2:$SERVER2DIR
 
@@ -528,7 +532,7 @@ Add release to history page:
 
 ## Tell others about release
 
-- If release candidate (just a short invitation to test):
+- If release candidate (just a short invitation to test it):
   - <grass-dev at lists.osgeo.org>
   - <grass-user at lists.osgeo.org>
 


=====================================
grasslib.dox
=====================================
@@ -203,9 +203,9 @@ as follows:
 
 <!--
   original:
-  doc/help_loc_structure.odg
+  doc/help_project_structure.odg
 -->
-\image html "loc_struct.png" "Diagram of GRASS file structure"
+\image html "help_project_structure.png" "Diagram of GRASS file structure"
 
 \section Compiling_and_Installing_GRASS_Modules Compiling and Installing GRASS Modules
 


=====================================
gui/wxpython/gmodeler/dialogs.py
=====================================
@@ -412,12 +412,10 @@ class ModelRelationDialog(wx.Dialog):
             flag=wx.EXPAND | wx.LEFT | wx.RIGHT | wx.BOTTOM,
             border=5,
         )
-        mainSizer.Add(
-            btnSizer, proportion=0, flag=wx.EXPAND | wx.ALL | wx.ALIGN_CENTER, border=5
-        )
+        mainSizer.Add(btnSizer, proportion=0, flag=wx.EXPAND | wx.ALL, border=5)
 
         self.panel.SetSizer(mainSizer)
-        mainSizer.Fit(self.panel)
+        mainSizer.Fit(self)
 
         self.Layout()
         self.SetSize(self.GetBestSize())


=====================================
gui/wxpython/gmodeler/panels.py
=====================================
@@ -67,7 +67,6 @@ from gmodeler.giface import GraphicalModelerGrassInterface
 from gmodeler.model import (
     Model,
     ModelAction,
-    ModelData,
     ModelRelation,
     ModelLoop,
     ModelCondition,
@@ -1136,7 +1135,7 @@ class ModelerPanel(wx.Panel, MainPageBase):
         """Add data item to model"""
         # add action to canvas
         width, height = self.canvas.GetSize()
-        data = ModelData(
+        data = ModelDataSingle(
             self, x=width / 2 + self._randomShift(), y=height / 2 + self._randomShift()
         )
 


=====================================
include/VERSION
=====================================
@@ -1,4 +1,4 @@
 8
 4
-0RC1
+0
 2024


=====================================
lib/init/Makefile
=====================================
@@ -25,7 +25,7 @@ FILES = \
 	$(ETC)/echo$(EXE) \
 	$(ETC)/license \
 	$(ETC)/VERSIONNUMBER \
-	$(HTMLDIR)/help_loc_struct.png \
+	$(HTMLDIR)/help_project_structure.png \
 	$(HTMLDIR)/grassdb.png \
 	$(HTMLDIR)/location.png \
 	$(HTMLDIR)/location-add.png \


=====================================
lib/init/help_loc_struct.png deleted
=====================================
Binary files a/lib/init/help_loc_struct.png and /dev/null differ


=====================================
lib/init/help_project_structure.png
=====================================
Binary files /dev/null and b/lib/init/help_project_structure.png differ


=====================================
lib/loc_struct.png deleted
=====================================
Binary files a/lib/loc_struct.png and /dev/null differ


=====================================
raster/r.in.pdal/info.cpp
=====================================
@@ -116,7 +116,7 @@ void print_lasinfo(struct StringList *infiles)
         std::cout << "Point offset: " << h.pointOffset() << "\n";
         std::cout << "Point count: " << h.pointCount() << "\n";
         for (size_t i = 0; i < pdal::LasHeader::RETURN_COUNT; ++i)
-            std::cout << "Point count by return[" << i << "]: "
+            std::cout << "Point count by return[" << i + 1 << "]: "
                       << const_cast<pdal::LasHeader &>(h).pointCountByReturn(i)
                       << "\n";
         std::cout << "Scales X/Y/Z: " << h.scaleX() << "/" << h.scaleY() << "/"


=====================================
raster/r.li/r.li.html
=====================================
@@ -211,7 +211,7 @@ for more information about development.
 McGarigal, K., and B. J. Marks. 1995. FRAGSTATS: spatial pattern
 analysis program for quantifying landscape structure. USDA For. Serv.
 Gen. Tech. Rep. PNW-351
- (<a href="http://www.fs.fed.us/pnw/pubs/gtr_351.pdf">PDF</a>).
+ (<a href="https://research.fs.usda.gov/treesearch/3064">PDF</a>).
 
 <li>
 Baker, W.L. and Y. Cai. 1992. The r.le programs for multiscale analysis of


=====================================
utils/generate_release_notes.py
=====================================
@@ -66,7 +66,7 @@ def split_to_categories(changes, categories):
 
 
 def print_section_heading_2(text, file=None):
-    print(f"### {text}\n", file=file)
+    print(f"## {text}\n", file=file)
 
 
 def print_section_heading_3(text, file=None):
@@ -123,11 +123,35 @@ def print_by_category(changes, categories, file=None):
 
 def binder_badge(tag):
     """Get mybinder Binder badge from a given tag, hash, or branch"""
-    binder_image_url = "https://camo.githubusercontent.com/581c077bdbc6ca6899c86d0acc6145ae85e9d80e6f805a1071793dbe48917982/68747470733a2f2f6d7962696e6465722e6f72672f62616467655f6c6f676f2e737667"  # noqa
+    binder_image_url = "https://mybinder.org/badge_logo.svg"
     binder_url = f"https://mybinder.org/v2/gh/OSGeo/grass/{tag}?urlpath=lab%2Ftree%2Fdoc%2Fnotebooks%2Fjupyter_example.ipynb"  # noqa
     return f"[![Binder]({binder_image_url})]({binder_url})"
 
 
+def adjust_after(lines):
+    """Adjust new contributor lines in the last part of the generated notes"""
+    bot_file = Path("utils") / "known_bot_names.txt"
+    known_bot_names = bot_file.read_text().splitlines()
+    new_lines = []
+    for line in lines:
+        if line.startswith("* @"):
+            unused, username, text = line.split(" ", maxsplit=2)
+            username = username.replace("@", "")
+            if username in known_bot_names:
+                continue
+            output = subprocess.run(
+                ["gh", "api", f"users/{username}"],
+                capture_output=True,
+                text=True,
+                check=True,
+            ).stdout
+            name = json.loads(output)["name"]
+            if name and name != username:
+                line = f"* {name} (@{username}) {text}"
+        new_lines.append(line)
+    return new_lines
+
+
 def print_notes(
     start_tag, end_tag, changes, categories, before=None, after=None, file=None
 ):
@@ -145,6 +169,8 @@ def print_notes(
 
     if before:
         print(before)
+    print_section_heading_2("Highlights", file=file)
+    print("* _Put handcrafted list of items here._\n")
     print_section_heading_2("What's Changed", file=file)
     changes_by_category = split_to_categories(changes, categories=categories)
     print_by_category(changes_by_category, categories=categories, file=file)
@@ -185,12 +211,13 @@ def notes_from_gh_api(start_tag, end_tag, branch, categories, exclude):
         else:
             changes.append(change)
     changes = remove_excluded_changes(changes=changes, exclude=exclude)
+    after = adjust_after(lines[end_whats_changed + 1 :])
     print_notes(
         start_tag=start_tag,
         end_tag=end_tag,
         changes=changes,
         before="\n".join(lines[:start_whats_changed]),
-        after="\n".join(lines[end_whats_changed + 1 :]),
+        after="\n".join(after),
         categories=categories,
     )
 



View it on GitLab: https://salsa.debian.org/debian-gis-team/grass/-/compare/3f6164bffb9afb2e8524aaf41efacdcac87e3eda...ff425b7757940c52bbd3f305bac6767242b0a793

-- 
This project does not include diff previews in email notifications.
View it on GitLab: https://salsa.debian.org/debian-gis-team/grass/-/compare/3f6164bffb9afb2e8524aaf41efacdcac87e3eda...ff425b7757940c52bbd3f305bac6767242b0a793
You're receiving this email because of your account on salsa.debian.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-grass-devel/attachments/20240727/9dbe8785/attachment-0001.htm>


More information about the Pkg-grass-devel mailing list