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

2024-02-22 Thread 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

2024-02-22 Thread 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.
> *

Re: [GRASS-dev] GRASS Teams on GitHub

2024-02-22 Thread Huidae Cho via grass-dev 
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

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

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

I think we need this team.
* grass-docker-homebrew-users
 Users for
automated dockerhub and homebrew builds

I believe we can consolidate these two teams.
* grass-promo-write
 Contributors
to GRASS GIS promo repo with write access
* grass-website-write
 Maintainers of
GRASS GIS website

What about these two?
* grass-discussion-moderators
 Discussion
moderators with general Triage access
* grass-triage  Contributors
with PR and issue triage power

Best,
Huidae

[1] https://github.com/orgs/OSGeo/teams

On Thu, Feb 22, 2024 at 1:35 AM Ondřej Pešek via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Sweet devs,
>
> Looking at the GitHub teams within the OSGeo organisation [1], it is
> impossible not to notice the fact that the GRASS people are very good
> in making themselves visible through visual weed infestation. On one
> side, it is nice to see GRASS all over the dance floor; on the other
> one, I don't find it particularly polite to storm the org and see that
> GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in
> total).
>
> Wouldn't it be better to follow the example of GDAL instead? Creating
> only one master team (grass) and then 11 child teams (grass-write,
> grass-addons-write, ...)? It would make the org team overview much
> cleaner. Also, you could see all grass child teams' members in one
> place.
>
> In the name of New GitHub Order,
> Ondrej
>
> PS: I also believe that we should reduce the number of GRASS teams and
> consolidate some (grass-addons-subversion-committers ->
> grass-addons-write) but I guess this is for another and much more
> contentious discussion.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>


-- 
Huidae Cho, Ph.D., GISP, /hidɛ 
t͡ɕo/, 조희대, 曺喜大
GRASS GIS Developer
https://idea.isnew.info/
___
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.3.2

2024-02-22 Thread Anna Petrášová via grass-dev 
On Thu, Feb 22, 2024 at 12:33 PM Markus Neteler  wrote:

> On Thu, Feb 22, 2024 at 3:59 PM Anna Petrášová 
> wrote:
> > On Tue, Feb 20, 2024 at 5:45 PM Markus Neteler via grass-dev <
> grass-dev@lists.osgeo.org> wrote:
> ...
> >> Hopefully no RC2 is needed.
> >
> > Markus,
> >
> > a bug in r.horizon came up on gitter recently:
> > https://github.com/OSGeo/grass/pull/3441
> >
> > It would be nice to include it in 8.3.2 (with all the other fixes in
> r.horizon) but at the same time I don't want to
> > trigger RC2 because of this... The bug fix is a small change in
> r.horizon not impacting anything else, so
> > perhaps we wouldn't need RC2? What do you think?
>
> For me that's okay as it is very isolated.
> Feel free to backport it.
>
>
Done!


> Markus
>
___
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.3.2

2024-02-22 Thread Veronica Andreo via grass-dev 
Markus, all,

Great! Thanks a lot!

Zenodo link works, but the doi link yields doi not found page... is it ok
for the resolver link to take a couple of days?

Vero

El mar, 20 feb 2024 a las 19:45, Markus Neteler via grass-dev (<
grass-dev@lists.osgeo.org>) escribió:

> Hi devs,
>
> On Thu, Feb 1, 2024 at 10:40 PM Markus Neteler  wrote:
> > We have accumulated a number of fixes in the past weeks.
> >
> > Here the milestone:
> > https://github.com/OSGeo/grass/milestone/24
>
> The RC1 release is now available, please test it:
> https://github.com/OSGeo/grass/releases/tag/8.3.2RC1
>
> The open issues/PR I have moved to a new 8.3.3 milestone. But let's
> focus on 8.4.0.
>
> And yay, the Zenodo bridge works again:
> Version 8.3.2RC1: https://zenodo.org/records/10685321
> DOI: https://doi.org/10.5281/zenodo.10685321 (resolver link will work
> in some hs from now)
>
> Hopefully no RC2 is needed.
>
> Thanks to all contributors,
> Markus
>
> --
> Markus Neteler, PhD
> https://www.mundialis.de - company
> https://grass.osgeo.org - FOSS
> https://neteler.org - freelancing & blog
> ___
> 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

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

2024-02-22 Thread Markus Neteler via grass-dev 
On Thu, Feb 22, 2024 at 3:59 PM Anna Petrášová  wrote:
> On Tue, Feb 20, 2024 at 5:45 PM Markus Neteler via grass-dev 
>  wrote:
...
>> Hopefully no RC2 is needed.
>
> Markus,
>
> a bug in r.horizon came up on gitter recently:
> https://github.com/OSGeo/grass/pull/3441
>
> It would be nice to include it in 8.3.2 (with all the other fixes in 
> r.horizon) but at the same time I don't want to
> trigger RC2 because of this... The bug fix is a small change in r.horizon not 
> impacting anything else, so
> perhaps we wouldn't need RC2? What do you think?

For me that's okay as it is very isolated.
Feel free to backport it.

Markus
___
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.3.2

2024-02-22 Thread Anna Petrášová via grass-dev 
On Tue, Feb 20, 2024 at 5:45 PM Markus Neteler via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Hi devs,
>
> On Thu, Feb 1, 2024 at 10:40 PM Markus Neteler  wrote:
> > We have accumulated a number of fixes in the past weeks.
> >
> > Here the milestone:
> > https://github.com/OSGeo/grass/milestone/24
>
> The RC1 release is now available, please test it:
> https://github.com/OSGeo/grass/releases/tag/8.3.2RC1
>
> The open issues/PR I have moved to a new 8.3.3 milestone. But let's
> focus on 8.4.0.
>
> And yay, the Zenodo bridge works again:
> Version 8.3.2RC1: https://zenodo.org/records/10685321
> DOI: https://doi.org/10.5281/zenodo.10685321 (resolver link will work
> in some hs from now)
>
> Hopefully no RC2 is needed.
>

Markus,

a bug in r.horizon came up on gitter recently:
https://github.com/OSGeo/grass/pull/3441

It would be nice to include it in 8.3.2 (with all the other fixes in
r.horizon) but at the same time I don't want to trigger RC2 because of
this... The bug fix is a small change in r.horizon not impacting anything
else, so perhaps we wouldn't need RC2? What do you think?


> Thanks to all contributors,
> Markus
>
> --
> Markus Neteler, PhD
> https://www.mundialis.de - company
> https://grass.osgeo.org - FOSS
> https://neteler.org - freelancing & blog
> ___
> 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.3.2

2024-02-22 Thread Martin Landa via grass-dev 
Hi,

út 20. 2. 2024 v 23:45 odesílatel Markus Neteler via grass-dev <
grass-dev@lists.osgeo.org> napsal:

> The RC1 release is now available, please test it:
> https://github.com/OSGeo/grass/releases/tag/8.3.2RC1


please test

* Windows installer:
https://grass.osgeo.org/grass83/binary/mswindows/native/WinGRASS-8.3.2RC1-1-Setup.exe
* Ubuntu Expr PPA:
https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-experimental

Thanks, Martin

-- 
Martin Landa
https://geomatics.fsv.cvut.cz/en/employees/martin-landa/
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS Teams on GitHub

2024-02-22 Thread Ondřej Pešek via grass-dev 
Sweet devs,

Looking at the GitHub teams within the OSGeo organisation [1], it is
impossible not to notice the fact that the GRASS people are very good
in making themselves visible through visual weed infestation. On one
side, it is nice to see GRASS all over the dance floor; on the other
one, I don't find it particularly polite to storm the org and see that
GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in
total).

Wouldn't it be better to follow the example of GDAL instead? Creating
only one master team (grass) and then 11 child teams (grass-write,
grass-addons-write, ...)? It would make the org team overview much
cleaner. Also, you could see all grass child teams' members in one
place.

In the name of New GitHub Order,
Ondrej

PS: I also believe that we should reduce the number of GRASS teams and
consolidate some (grass-addons-subversion-committers ->
grass-addons-write) but I guess this is for another and much more
contentious discussion.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev