[GRASS-dev] Save the Date: GRASS Developer Summit Raleigh 2025

[Vaclav Petras via grass-dev]

Dear all,

It is my pleasure to announce that we will meet in 2025 and spend time
together focused on improving GRASS GIS. Please mark your calendars for the
GRASS Developer Summit in Raleigh, May 19-24, 2025. Help us plan better by
filling out an interest form:

https://forms.gle/uzQqgayYC7F4kLCZ8

The event will be the main community meeting for 2025 and will be hosted at
North Carolina State University.

Feel free to ping me if you have any questions,
Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New features provided by Nix

[Vaclav Petras via grass-dev]

Thanks Ivan, it looks quite useful and I plan to use it when I update my
system in a month or so.

On Fri, 28 Jun 2024 at 03:41, Ivan Mincik via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Hi people !
>
> Recently, I had a pleasure to join GRASS Community Meeting in Prague and
> had a presentation about Nix [1] and potential benefits it can bring to
> a GRASS community. It was quite well received and now it is a real thing
> [2] (+ few more PRs).
>
>
> # What Nix can do for you ?
>
> 1. Create a full development environment by running single `nix develop`
> command
>
> 2. Run GRASS directly from a Git source code (from any branch, tag or
> checkout which contains nix files added in #3889)
>
> 3. A lot more
>
>
> # How to use it ?
>
> Please check out PR #3889 [1] description for the instructions. It is
> just about installing Nix and then you can start running some magic
> commands.
>
> I am still struggling how to integrate this information to a GRASS Wiki.
>
>
> # My Nix presentation
>
> Markdown version of my GRASS Community meeting presentation containing
> some more very interesting examples can be found here [3].
>
> Have a nice day !
>
>
> 1 - https://nix.dev/
> 2 - https://github.com/OSGeo/grass/pull/3889
> 3 -
>
> https://github.com/imincik/nix-presentations/blob/master/grass-community-meeting-2024/presentation.md
>
> --
> Ivan Minčík, ivan.min...@gmail.com
>
> GPG: https://imincik.github.io/0xDDDF983F.key
> Matrix:  @imincik:matrix.org
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [PROJ] PROJ was not updated in Zenodo

[Vaclav Petras via grass-dev]

Thanks Even. This is not clear to me. I see OSGeo/grass enabled. I can't
manage that because it says that it is managed by another user of my org.
Screenshot attached.

Vaclav

On Tue, 4 Jun 2024 at 10:29, Even Rouault via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Hi,
>
> see below. I also see in https://zenodo.org/account/settings/github/ that
> the OSGeo/GRASS repository is disabled. I suspect it needs to be turned on
> again, otherwise the next GRASS release will probably lack a Zenodo record
> Even
>
>  Message transféré 
> Sujet : Re: [PROJ] PROJ was not updated in Zenodo
> Date : Tue, 4 Jun 2024 16:25:42 +0200
> De : Even Rouault via PROJ  
> Répondre à : Even Rouault 
> 
> Pour : Peter Löwe  , Javier
> Jimenez Shaw  
> Copie à : proj  
>
> Hi,
>
> I've posted the following message through Zenodo support form at
> https://zenodo.org/support
>
> 
>
> Hi,
> The PROJ project has released a new GitHub release at
> https://github.com/OSGeo/PROJ/releases/tag/9.4.1 a couple days ago but no
> new corresponding Zenodo record has been created at
> https://zenodo.org/records/5884394  , despite the GitHub integration
> being set up.
> I see from my account in https://zenodo.org/account/settings/github/ that
> the repository seems to have been disabled, although it was enabled last
> time. It seems something regularly disable repositories... ? I've just
> re-enabled it (as well as other repositories such as OSGeo/gdal and
> mapserver/mapserver that were disabled). Could you trigger the creation of
> a new record for the 9.4.1 release ? And what's the reason for this
> apparent disabling of repositories?  This isn't the first time it happens
> Best regards,
> Even Rouault
>
> """
>
> I'm proposing to add a step in HOWTO-RELEASE so we check that before doing
> the release : https://github.com/OSGeo/PROJ/pull/4162 , pending Zenodo
> figures out why the repositories get regularly disabled...
>
> Even
>
>
> Le 04/06/2024 à 12:20, Peter Löwe via PROJ a écrit :
>
> Javier, all,
>
> whoever handled the latest release should contact the Zenodo helpdesk
> https://zenodo.org/support about the missing version DOI.
>
> BTW, the PROJ page at OSGeo (https://www.osgeo.org/projects/proj/) seems
> to be outdated (PROJ 9.0.0).
>
> Best,
> Peter
>
>  
>
>
> *Gesendet:* Montag, 03. Juni 2024 um 21:56 Uhr
> *Von:* "Javier Jimenez Shaw"  
> *An:* "proj"  , "Peter Löwe"
>  
> *Betreff:* PROJ was not updated in Zenodo
> Hi PROJ
>
> I "was" by accident in Zenodo today, and I think it was not updated with
> the last release of PROJ
> https://zenodo.org/records/10818825
> Is it still failing, Peter?
>
> Cheers
> Javier
>
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
>
> ___
> PROJ mailing 
> listPROJ@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/proj
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 8.4.0

[Vaclav Petras via grass-dev]

On Fri, 26 Apr 2024 at 05:36, Markus Neteler via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> The remainder for the 8.4.0 milestone are (currently) 104 open pull
> requests (PRs) which still need testing or review or to be postponed:
> https://github.com/OSGeo/grass/pulls?q=is%3Aopen+is%3Apr+milestone%3A8.4.0
>

This is now down to 27. Kudos to Anna, myself and others.

I created a Future milestone discussed earlier to help with the management.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2024 - Add EODAG support to GRASS GIS

[Vaclav Petras via grass-dev]

Hi and welcome Hamed,

On Mon, 18 Mar 2024 at 20:10, Hamed A. Elgizery via grass-dev <
grass-dev@lists.osgeo.org> wrote:

>
> Can you please guide me with any materials — if available — regarding the
> datasets? And if there is an issue “test of skills” available that is
> related to EODAG, since there are no issues associated with this task here:
> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#:~:text=i.landsat.download-,Test%20of%20skills%3A,-GUI%3A%20Add%20space
>

This was suggested in the past by Luca as a test of skills for this topic:

https://github.com/OSGeo/grass-addons/issues/1033

Best,
Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS Teams on GitHub

[Vaclav Petras via grass-dev]

On Fri, 8 Mar 2024 at 09:10, Ondřej Pešek  wrote:

>
> @Vaclav: Do you have some more points against the master-children
> schema? It seems that the general agreement is *for* the restructuring
> into parent and children teams. So far the only point against was "I
> didn't find team nesting particularly useful and we already had a
> couple of top-level teams."


...and I didn't see it working for GDAL with people both in the parent team
and child teams and repos being assigned to both levels.

How do you suggest we do it? Empty parent team without repos? Would that
look good?


> Although I appreciate all the work you
> dedicate to the GitHub management, I don't think that this is a valid
> point against when compared to the positive ones (although it's
> understandable that nobody wants to drop something that they have just
> created).
>

Thanks. It is more that before it was a high priority for me to get access
rights in order (access rights to individuals both directly and through
teams, inactive people from 2000s and early 2010s grandfathered into GitHub
write access, ...). These parent-child teams are low priority compared to
that.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.copy doesn't respect computational region??

[Vaclav Petras via grass-dev]

On Sat, 2 Mar 2024 at 07:04, Paulo van Breugel via grass-dev <
grass-dev@lists.osgeo.org> wrote:

>
>
> On March 2, 2024 1:00:23 AM GMT+01:00, Michael Barton via grass-dev <
> grass-dev@lists.osgeo.org> wrote:
> >It's been awhile since I've done this but I thought I remembered that a
> new map created with r.copy is constrained by the computational region.
> That does not seem to the case, at least in 8.4 dev. Maybe it has been this
> way for awhile (long while?) and I didn't notice it.
>


g.copy is a general tool which creates a copy of the data. Perhaps you are
interested in r.clip which is a raster tool and is driven by the
computational region as expected. r.clip clips according to the current
computation region (preserves original raster alignment  by default).

https://grass.osgeo.org/grass-stable/manuals/addons/r.clip.html


>
> I think, but I'm not 100% sure, that has always been the case.


Here is g.copy documentation from v6.4 it does not mention anything about
region. It seems to go back to US Army CERL.

https://github.com/OSGeo/grass-legacy/blob/2734c86fd5cb976b4a94b04a2cdc75b4613f6a77/general/manage/cmd/g.copy.html#L6


> In any case, it seems to be the logical behavior, otherwise it wouldn't be
> a true copy?
>

Are the different expectations coming from differences between raster tools
and general tools? With r.copy (as opposed to g.copy), you could perhaps
argue for respecting the computational region, but I think the "true copy"
expectation would still be strong.

Vaclav


>
>
> >
> >Michael
> >_
> >
> >C. Michael Barton
> >Associate Director, School of Complex Adaptive Systems (
> https://scas.asu.edu)
> >Professor, School of Human Evolution & Social Change (
> https://shesc.asu.edu)
> >Director, Center for Social Dynamics & Complexity (
> https://complexity.asu.edu)
> >Arizona State University
> >Tempe, AZ 85287-2701
> >USA
> >
> >Executive Director, Open Modeling Foundation (
> https://openmodelingfoundation.github.io<
> https://openmodelingfoundation.github.io/>)
> >Director, Network for Computational Modeling in Social & Ecological
> Sciences (https://comses.net)
> >
> >personal website: http://www.public.asu.edu/~cmbarton
> >
> >
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS GIS: backport of CI speed updates to G83?

[Vaclav Petras via grass-dev]

On Tue, 20 Feb 2024 at 04:14, Markus Neteler via grass-dev <
grass-dev@lists.osgeo.org> wrote:

>
> In fact the slowest CI run determines how much time I have to wait
> with each release step (i.e., editing VERSION file, wait 1:30hs, do
> some steps, wait 1:30hs, create tarball, wait 1:30hs, reset VERSION
> file, wait 1:30hs ... which is a pain).
>

Isn't the issue the release procedure itself? It has a bunch of steps which
need to be done manually.

I counted 3 pushes which is what triggers the CI.

1) release VERSION file push
2) tag push
3) development VERSION file push

The release needs step 2 to be completed. We were doing step 2 only after
CI for step 1 completed to make sure the CI runs on the branch at that time
before the tag is made in step 2. I guess the reason to wait after step 2
before doing step 3 is to make sure that the automated part of the release
procedure linked to step 2 actually went through. Is this correct?

Best,
Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS Teams on GitHub

[Vaclav Petras via grass-dev]

Huidae and Ondrej,

I recently restructured the teams to reflect GitHub workflows and resulting
needs for access (the original team structure was just used from Subversion
access). Another reason was getting a better control over who can change
the code directly (this is connected to the required PR reviews).

We have 11 teams to cover our 4 repos and different levels of access (plus
2+1 legacy teams). Less would not allow us to give people specific
properly-limited rights when needed, i.e., on a "need-to-have" basis. We
have the minimum number of teams to drive write access on repo-to-repo
basis to our 4 repos and make use of the 4 different relevant roles (4
Write teams, one for each repo, 1 Admin and 1 Maintain team for all repos,
1 Triage team, 1 special-purpose Triage team (discussion-moderators), 1
legacy Write (addons-subversion-committers), 1 legacy Triage
(subversion-committers), 1 legacy Read (docker-homebrew-users)). More would
be needed for specific task or organization reasons such as the current
grass-discussion-moderators. Another reason to add more (possibly nested
teams) would be when we would use it for reviews and/or notifications like
"someone from the Windows team needs to review this PR", but it seems we
are heading towards code owners rather than teams there (I don't pretend to
know what are the differences or overlaps here).

If we say we want to cut down the number of teams, we can remove one or
more of the following: 1 or 2 Subversion teams (legacy, but both are in use
now), homebrew-docker team (complete legacy), grass-addons-write (could be
merged with grass-write depending on how much it will be used, it has one
person who is not in grass-write), grass-promo-write (can be merged with
grass-website-write depending on in which way the grass-promo repo will be
used).

For comparison, GDAL has 2 teams for 3 repositories plus a top-level GDAL
team containing the two teams. gdal-admins has 9 members and the
gdal-committers team has 22 members (our grass-subversion-committers legacy
team has 33). gdal-admins has Admin for 2 repos and Write for 1 repo.
gdal-committers Write for 2 repos. The top-level GDAL team has 5 direct
members and 1 repo. The 3 repos are gdal, gdal-data, and shapelib (plus
there is 1 auto-updated repo and 2 legacy repos not managed using access
roles for teams). The two notable differences in the project structure
influencing the number and diversity of repos are that the GDAL website is
generated from the gdal repo and that GDAL drivers are either included in
gdal repo, (inactive) legacy repo or in separate repos (GDAL has 1 Write
team, we 3 extra teams). Additionally, we already had a need for a separate
Triage team and a GitHub Discussion-managing Triage team (2 extra teams).
We are not yet making use of the Maintain team (1 extra team).

More answers inline.

On Thu, 22 Feb 2024 at 14:51, Huidae Cho via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Ondrej,
>
> I agree with you that there are too many teams for GRASS [1] and they
> should be consolidated (or not, but at least moved) as child teams.
>
> Do we still need these subversion teams?
> * grass-subversion-committers
>  GRASS
> GIS Subversion committers
> * grass-addons-subversion-committers
>  GRASS
> GIS Addons Subversion committers
>

These are people who had access in the Subversion times. We want these past
Subversion-time contributors to have Triage rights (whatever that means).
The grass-addons repo works differently, so the Subversion-time group has
Write access there, but that can be changed in the future easily as this
group from pre-GitHub times is separate from the active group in
grass-addons-write.


> How is this team different from the above
> grass-addons-subversion-committers?
> * grass-addons-write
>  Maintainers of
> tools in GRASS GIS Addons with write access to the repository
>

This is the active team where new people would be added. The Subversion
team may move from Write to Triage in the future.


> How are these three teams different?
> * grass-admin  GRASS GIS
> repo administration team
> * grass-maintain  GRASS
> GIS repo settings maintenance team
> * grass-write  Maintainers
> of GRASS GIS with write access to the main repository
>

They have what GitHub calls Admin, Maintain, and Write access rights to the
repo. Write is only for code. Maintain is for some of the settings. for
Admin for access and security. See more here:

https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization


> I think we need this team.
> * grass-docker-homebrew-

Re: [GRASS-dev] GRASS GIS: backport of CI speed updates to G83?

[Vaclav Petras via grass-dev]

On Tue, 20 Feb 2024 at 06:45, Nicklas Larsson via grass-dev <
grass-dev@lists.osgeo.org> wrote:

>
> On 20 Feb 2024, at 10:14, Markus Neteler via grass-dev <
> grass-dev@lists.osgeo.org> wrote:
>
>
> In fact the slowest CI run determines how much time I have to wait
> with each release step (i.e., editing VERSION file, wait 1:30hs, do
> some steps, wait 1:30hs, create tarball, wait 1:30hs, reset VERSION
> file, wait 1:30hs ... which is a pain).
>
>
> I agree this is a case where we have limited ourself too much, with all
> those
> required 1.5 hrs tests, approval, etc. (not even [skip ci] would work) .
> What you
> would need is a (ideally) direct commit access or at least  “Rebase and
> merge”
> option to merge (thus enable a number of commits to be merged at one time,
> as opposed to "Squash and merge”).
>
> We must find a solution to improve this situation for preparing releases, I
> wouldn’t mind temporary lifting necessary constraints.
>

The backports and releases are done using direct commits and pushes. That's
how the rules are set, no bypass or exception is necessary for that.

I guess the issue is not that we can't bypass the check but that we want
the checks to pass because we don't want to base the release on a commit
with failing CI.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Vaclav Petras via grass-dev]

Seeing the new startup screen idea description, the "Proposals for a new
GRASS GIS startup mechanism" wiki page on Trac wiki might be a good read:

https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup

On Thu, 15 Feb 2024 at 14:11, Anna Petrášová via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> I believe the welcome screen would most likely be dismissed. The other
> possible solutions Brendan brings up may be difficult to implement with
> wxpython. But we tried to do something similar with Linda using the info
> bar, which shows info/buttons for first-time users. She tested that with
> mixed results, people often just dismissed it. But I think it could be
> further refined. For example, maybe we could move it to map display to make
> it more prominent. The other direction is to better detect when users are
> doing something likely wrong (import projected data to default project) and
> then suggest alternatives.
>
> On Thu, Feb 15, 2024 at 12:05 PM Brendan  wrote:
>
>> Personally I like the new interface, but Maris' proposal for wizards to
>> create new projects sounds helpful. Rather than a startup screen that
>> stalls users, there could be temporary icons floating on the map canvas
>> that prompt users to create a new project in different ways. Would
>> disappear as soon as data is added to the map. A helpful guide/shortcut
>> that users could choose to ignore. Still, any startup hints might be
>> annoying like Clippy the infamous paperclip. I can find an example from
>> other software if the idea is of interest. Or the logo that pops up when
>> you start GRASS could have buttons for creating new projects; if a user
>> doesn't click on them while GRASS is starting, then it will open in the
>> default / previous project.
>> Best, Brendan
>>
>> On Thu, Feb 15, 2024 at 8:35 AM Anna Petrášová via grass-dev <
>> grass-dev@lists.osgeo.org> wrote:
>>
>>> I agree with Vero. I am not sure we had enough time to evaluate the
>>> current state yet. I don't remember the details of our discussions, so if
>>> you provide a description of what exactly you mean, that would be helpful.
>>> In terms of a GSoC project, the main issue I see is that the mentors need
>>> to provide clear instructions on what the student should do, especially for
>>> this case, and we apparently don't have a consensus here. So I would be
>>> willing to mentor it only as long as we develop a plan ahead of time we can
>>> all agree on. Given the past experience, I am somewhat skeptical we can all
>>> agree on something:) But I'll try to be open to ideas!
>>>
>>> On Thu, Feb 15, 2024 at 8:12 AM Veronica Andreo 
>>> wrote:
>>>
 Hi Maris,

 Would you mind sharing more details on this idea? I'm afraid I was not
 able to attend/hear the discussion about this welcome screen in Prague. I
 hope though we do not end up with a new startup screen. It took so much
 time to reach an agreement and finally remove it.

 Vero

 El jue, 15 feb 2024 a las 9:00, Maris Nartiss ()
 escribió:

> Hello Anna, Vero.
> I added the welcome screen idea we discussed during our Prague
> meeting. I think it would be a good GSOC project as it is quite easy
> and at the same time will allow to understand if it is the way to go.
> Anna, would you be able to be a co-mentor as it is a GUI project? Or
> who else could be?
> Vero, your user-centric view also would be valuable.
> Please edit the wiki accordingly.
>
> Thanks,
> Māris.
>
> sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
> grass-dev () rakstīja:
> >
> > Hi,
> >
> > I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac
> wiki, which I think we should be moving away from):
> > https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
> >
> > It's not updated yet, I plan to add more topics. If you want to
> mentor a topic, we can discuss it here.
> >
> > Anna
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>


 --
 Dra. Verónica Andreo
 Investigadora Adjunta de CONICET
 Instituto Gulich (CONAE - UNC)
 Centro Espacial Teófilo Tabanera (CETT)
 Falda del Cañete - Córdoba, Argentina
 +54 3547 40 int. 1153
 https://veroandreo.gitlab.io/

>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Renaming location to project

[Vaclav Petras via grass-dev]

Dear dev list,

While the decision at the PSC meeting was to merge the first batch of
renames to have it in for 8.4 [1], the PRs [2] will need reviews to be
merged. Anyone can leave an approving review. One approving review from a
member of the grass-write team [3] will be needed to enable merging. For
your convenience, here are the links to the PRs:

https://github.com/OSGeo/grass/pull/2993
https://github.com/OSGeo/grass/pull/3131
https://github.com/OSGeo/grass/pull/3130
https://github.com/OSGeo/grass/pull/3133
https://github.com/OSGeo/grass/pull/3134

Best,
Vaclav

[1] https://trac.osgeo.org/grass/wiki/PSC/Minutes/PSC_Meeting_20240209
[2] https://github.com/orgs/OSGeo/projects/2
[3] https://github.com/orgs/OSGeo/teams/grass-write



On Thu, 21 Dec 2023 at 10:45, Vaclav Petras  wrote:

> Dear users and developers,
>
> We have a new development which will likely touch everyone, so I would
> like to make sure that everyone is informed and can prepare for or even
> help with the changes.
>
> After years of discussions, we are renaming the "location" concept in
> GRASS GIS to "project". While we confirmed we want to keep all the
> advantages of the current data hierarchy in GRASS GIS, the term "location"
> makes explaining and working with the hierarchy difficult. The new term
> "project" was chosen for the concept because it aligns with the place the
> concept has in GRASS GIS and how other software packages are using the
> term. The term "project" is also already used by many people who are
> explaining GRASS GIS data hierarchy in workshops, classes, and papers.
>
> Main transition will happen for 8.4 and is designed to be backward
> compatible until the 9.0 release.
>
> Many PRs are already in place:
>
> https://github.com/orgs/OSGeo/projects/2
>
> This text is a summary of a longer text in the related issue:
>
> https://github.com/OSGeo/grass/issues/3121#issuecomment-1866473182
>
> Best,
> Vaclav
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Renaming location to project

[Vaclav Petras via grass-dev]

Dear users and developers,

We have a new development which will likely touch everyone, so I would like
to make sure that everyone is informed and can prepare for or even help
with the changes.

After years of discussions, we are renaming the "location" concept in GRASS
GIS to "project". While we confirmed we want to keep all the advantages of
the current data hierarchy in GRASS GIS, the term "location" makes
explaining and working with the hierarchy difficult. The new term "project"
was chosen for the concept because it aligns with the place the concept has
in GRASS GIS and how other software packages are using the term. The term
"project" is also already used by many people who are explaining GRASS GIS
data hierarchy in workshops, classes, and papers.

Main transition will happen for 8.4 and is designed to be backward
compatible until the 9.0 release.

Many PRs are already in place:

https://github.com/orgs/OSGeo/projects/2

This text is a summary of a longer text in the related issue:

https://github.com/OSGeo/grass/issues/3121#issuecomment-1866473182

Best,
Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Daily build for Windows outdated

[Vaclav Petras via grass-dev]

On Mon, 9 Oct 2023 at 02:41, Martin Landa  wrote:

>
> right, the build process was broken. Fixed. Martin
>


Thank you! Looks good. Revision 632b22970e is the latest on main.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Daily build for Windows outdated

[Vaclav Petras via grass-dev]

Dear Martin and grass-dev,

The daily build for Windows seems outdated to me. The file at

https://wingrass.fsv.cvut.cz/grass84/

is from today, but the commit hash is df2c0bc922 which is this commit:

https://github.com/OSGeo/grass/commit/df2c0bc922

from June 7. This is the date in the logs.

Can you please look into this?

Thanks,
Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev