Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2
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
Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2
On Tue, Feb 20, 2024 at 9:29 PM Markus Neteler wrote: > > On Fri, Feb 16, 2024 at 5:20 PM Martin Landa wrote: > >> > Markus, can we start the procedure of releasing GRASS 8.3.2RC1? > >> > >> Yes, I'll do as soon as I find 3-4 hs of free time in a row. > >> Hopefully in the next days. > > > > Great, thanks a lot. Martin > > Procedure started. > Due to the long CI (GitHub actions) processes in G8.2 this will take > multiple hours. Obviously G8.3. > I'll notify once I am done. Markus ___ 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?
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] [release planning] GRASS GIS 8.3.2
On Fri, Feb 16, 2024 at 5:20 PM Martin Landa wrote: >> > Markus, can we start the procedure of releasing GRASS 8.3.2RC1? >> >> Yes, I'll do as soon as I find 3-4 hs of free time in a row. >> Hopefully in the next days. > > Great, thanks a lot. Martin Procedure started. Due to the long CI (GitHub actions) processes in G8.2 this will take multiple hours. I'll notify once I am done. 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
Re: [GRASS-dev] GSoC Ideas
Thanks Maris for the long reply, see below On Fri, Feb 16, 2024 at 1:42 PM Maris Nartiss wrote: > Hello all, > although I expected some discussion, I didn't expect a kind of Spanish > Inquisition. To make things easier for me (I still have to type single > handed), I'll try to address all issues in a single email. Well, we have been discussing this topic for a loong time, so you should have expected more passionate responses... > > At first we all must agree that coordinate systems, geospatial data > and thus also GIS is hard. We will never have a perfect (the final) > solution or a solution we all can agree on, but it shouldn't stop us > from trying out new things. > Sure. > > Second – from the GSOC web site: „Google Summer of Code is a global, > online program focused on bringing new contributors into open source > software development.“ It is not „get some code to merge into next > release“ and thus developing an experimental feature still is a good > way how to get familiar with the code base, contributing to os, issues > and features of GRASS. > If I invest my time into GSoC, I want the result to be merged. So personally, I am not going to mentor an "experimental" project. We have done this before, students didn't stay with the project and we had unusable results at the end. > > Third – we should improve GRASS with a goal of making easy to do „the > right thing“ and to make hard to do „wrong“. We have (and should > keep!) plenty of „shortcuts“ for experienced users who understand what > they do. > Generally I agree. > > And now let's dive into specifics (in chronological order). > Vero, I meant a first-run wizard, but choose a bad name. Sorry, my > fault. Although I had no fundamental objections against the old > startup screen, there is no need to resurrect it. He's dead, Jim. > > Anna, there were many ideas floating around in Prague caused by the > „location“->„project“ proposal. And you are right, we couldn't agree > on a single solution (see the first point of this email). At the same > time there were concerns from me and others (IIRC Martin, Luís, > Helmut?) that it is still too easy to continue with a sub-optimal or > outright wrong CRS (location/project structure). Later on (after a few > too many beers) I tried to convince everyone (sorry Linda!) that we > should focus on that “easy to do right“ mantra. At the end we all > agreed (or everyone agreed just to silence me ;-) that we should > continue exploring alternatives and thus was the GSOC proposal. > I share the concerns, I personally just don't think any welcome screen or wizard is going to address them. They would likely be dismissed and then we are in the same situation. We have had welcome screen and wizard for a long time and that was a stumbling block for users. I don't think simply redesigning it helps. We should think of some other ways, I don't have a solution now, if we have, we can have a GSoC project. > Brendan, there's more than one way to skin a cat. > > Anna, the current info bar is just bad for at least two reasons (sorry > Linda, I'm just opinionated). Although you state that most users just > dismiss it, I'll call it a lie – it is not possible to dismiss it at > all! Yeah, I'm just kidding, there is a bug in the code. I rm'ed my > .grass8 to see first start-up experience. See attachment with a cutout > from a full screen window I was presented with – one can not read > whole message or see any buttons as the widget is too small to fit all > of its content. And that's even before the text is translated to > Latvian, German or Finnish that will make the text even longer > (Äteritsiputeritsipuolilautatsijänkä is an actual name of region in > Lapland and makes a good word to test UI). > The info bar has fallen into the old startup window trap – try to > explain GRASS specifics (an important thing!) instead of providing > easy actionable options that all lead to „doing it right“. It is a > TL;DR, and why I should „create new project“ if I already have one > open? Keep in mind attention span of a goldfish (a.k.a. length of a > Tiktok video) we are dealing with. (Has anyone read this far? Let me > know in the comments and don't forget to like and subscribe.) > My idea did not interfere with implementing an offer to create a new > project in import tools if a reprojection from projected to ll project > is detected (I <3 how this sentence rolls-off my tongue) or any other > enhancements that also can (and should) be implemented. > Could you please create an issue for this? > > Vaclav, thanks. I was thinking of something like A1 proposal, but even > simpler (three + 1 buttons) and the same time with a lot of black > magick (e.g. three clicks or less to have everything ready for any of > our intro tutorials, including opening a web browser with the chosen > tutorial and adding some layers to the map view; two clicks (+ file > browsing) to have users raster or vector data displayed). > I think Vashek's point
Re: [GRASS-dev] GRASS GIS: backport of CI speed updates to G83?
But as one of the members with the maintain role (higher than triage and write), he has access to bypass permissions. If you go look back in the PR where I explained the branch rules, I showed the checkbox that allows to bypass for example in PRs. Here is the public combined view of the rules that are active for releasebranch_8_3 https://github.com/OSGeo/grass/rules/270686?ref=refs%2Fheads%2Freleasebranch_8_3 and https://github.com/OSGeo/grass/rules?ref=refs%2Fheads%2Freleasebranch_8_3 Note how they are different than https://github.com/OSGeo/grass/rules?ref=refs%2Fheads%2Fmain It was made such as changing workflow requirements for main don’t restrict the older branches to be merged, or that changes in the CI infrastructure (outside of our repo) make it so they don’t work anymore. So they are kind of run on a best-effort basis, instead of religiously. Edouard Choinière Le 20 févr. 2024 à 06:45, Nicklas Larsson a écrit : On 20 Feb 2024, at 10:14, Markus Neteler via grass-dev mailto: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. ___ 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?
Releasebranches don’t require workflows to pass now so he cannot use auto-merge. But once tests of the OSGeo4W are started, since they don’t fail the CI, you could just not wait, it won’t change anything. Edouard Choinière Le 20 févr. 2024 à 06:45, Nicklas Larsson a écrit : On 20 Feb 2024, at 10:14, Markus Neteler via grass-dev mailto: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. ___ 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?
> On 20 Feb 2024, at 10:14, Markus Neteler via grass-dev > mailto: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.___ 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?
On Tue, Feb 20, 2024 at 1:59 AM Edouard Choinière wrote: > > I don’t know a lot about backporting, If "lucky", then it is just git cherry-pick > but if you’re talking about splitting of the Ubuntu workflow’s gunittest > tests, I don’t see a reason why the content of the changes couldn’t be copied > to a new commit for that branch too. Since they are ran less often, the tests > could be split in three or even 4 jobs, where the %of time spent compiling > the same code would be a bit higher, but the time for all tests to run could > be smaller. The tests in the temporal folder still take half the total test > time though. > > If you are talking about the macOS arm runner, it might require some other > changes to port. My opinion would be to leave that alone in the 8.3 as > pre-arm code. But the same splitting could easily be done for 8.3, and split > as wished. 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). > In main, for macOS workflows, with only 20-25 mins spent on tests, with 3-4 > min spent on compiling, I don’t see the need to split it. Okay. > Windows workflows I don’t think it’s advantageous, as more than 20 mins is > spent before starting tests. Alright. Perhaps I have simply go through it again and hope that we abandon 8.3 soon :-) Best Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
