[GRASS-dev] grass-session integration into core

[Markus Neteler]

Hi devs,

Vaclav Petras  schrieb am Mi., 9. Juni 2021,
05:22:

> ...anyway, I think the ultimate fix is to build usable images from GRASS
> source code without a 3rd party library which is not an official
> dependency. Either GRASS needs grass-session to work and then it should be
> part of the source code or GRASS should be fixed to work without it.
>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub
> ,
>

Following this comment I'd like to open the discussion: also in my view we
need to make grass-session part of core. And that in a way that it can be
split out easily as a pip package or whatever appropriate.

Opinions are welcome!

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

Re: [GRASS-dev] Parallelization of existing modules for GRASS GIS

[Huidae Cho]

Aaron,

Thanks for the update. Please take a look at r.mapcalc if it's feasible to
parallelize it. It is probably one of the most frequently used raster
modules.

Best,
Huidae


On Mon, Jun 7, 2021 at 5:56 AM Aaron Saw Min Sern 
wrote:

> Hi everyone,
>
> The bonding period has just ended. Here's a short summary of what I have
> completed so far.
>
> 1) What did I get done during this period?
>
>- I have set up a wiki page detailing my project and its progress. [1]
>- I have set up my development environment. Here's the link to my
>repository. [2]
>- I have gotten in touch with my mentors, and we are arranging a
>meeting this week.
>
> 2) What do I plan on doing next week?
>
> I will be working on parallelizing 3 modules: *r.proj, r.neighbor,
> r.univar*. Based on the results, I will adjust my plans in the future
> weeks.
>
>
> 3) Am I blocked on anything?
>
> No, it has been good so far.
>
>
> Cheers,
> Aaron
>
> [1] https://trac.osgeo.org/grass/wiki/GSoC/2021/RasterParallelization
> [2] https://github.com/aaronsms/grass
> ___
> 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] Enable Zenodo before 7.8.6 and 8.0.0

[Peter Löwe]

Hi Vaclav, all,

 

maybe helpful:

 

The transient MOSS repo has been updated for CFF and codemeta.json:

 

https://github.com/ploewe/MOSS

 

The online CFF-generator didn't accept some of the attributes. Doublechecking of the output is recommended.

Further, we hijacked the CFF affiliation tag to include MARC relator/ role terms (https://www.loc.gov/marc/relators/relaterm.html), like the R community has done:

 

https://r-pkgs.org/description.html


"... A three letter code specifying the role. There are four important roles:


	
	cre: the creator or maintainer, the person you should bother if you have problems.
	
	
	aut: authors, those who have made significant contributions to the package.
	
	
	ctb: contributors, those who have made smaller contributions, like patches.
	
	
	cph: copyright holder. This is used if the copyright is held by someone other than the author, typically a company (i.e. the author’s employer).
	

..."

 

I will talk to the software citation folks to see how this is perceived.

 

Best,

Peter

 



 
 

Gesendet: Sonntag, 06. Juni 2021 um 05:33 Uhr
Von: "Vaclav Petras" 
An: "Peter Löwe" 
Cc: "grass-dev@lists.osgeo.org" 
Betreff: Re: Re: [release planning] Enable Zenodo before 7.8.6 and 8.0.0



Hi Peter, all, thanks for the answers. I have more questions assuming that's okay.
 


On Fri, Jun 4, 2021 at 2:57 AM Peter Löwe  wrote:








==> the CodeMeta-Project is currenlty pushing software citation standards: https://codemeta.github.io/








 

Thanks. The roles there seem to be more clear. Any opinion on CodeMata versus CFF (see also below)?

 








 


BTW, ways to retro-provide DOI versioning for previous GRASS releases would be an rewarding topic to discuss with Data Cite (the DOI infrastructure community).




 

Any opinions on how useful this is? We want a good archive of old versions, but does someone need DOIs for old releases?

 

==> This depends on wether the community wants to give due credit by citation to the persons which were involved in the previous releases.








 

Currently, the author list maintained in the source code is cumulative as far as I know, so old authors are still included as authors, so only use cases for that would be citing old releases in paper or by the new versions of software software. None seem likely to me. What do you think?

 











 




Any suggestions on includings DOI into source code? It seems to me that you can only use the generic/concept one and tell people to get the recent one. I didn't figure out the DOI reservation for GitHub repos.








 

Rather than where to put it - although that's important, too - my question is about which DOI? The main one everywhere or somehow try to put there the version specific one if that's even possible. It seems to me that the main DOI is the only feasible option.

 








==> A JSON file could be included. This way, the information is both readable for humans and automated access: https://codemeta.github.io/codemeta-generator/ 








 

I was thinking about the Citation File Format as I have seen it used quite a bit. Any opinions on that?

 






___
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: create new release branch

[Veronica Andreo]

Hello devs,

As you all know, grass birthday is approaching... July 29th is just around
the corner. I'd love to celebrate GRASS' bday with a new release, with a
big release ;)
Do you think that is doable? How much is missing for GRASS 8 release?

The next important date is FOSS4G 2021 on September 27th - October 2nd,
where we have proposed GRASS 8 talks and workshops. If we can't make it for
GRASS GIS' birthday, do you think it's feasible to release before FOSS4G,
say August for example?

I think it's really important to agree on a date so we can all manage our
reduced time and focus our efforts towards that aim.
What do you say?

Best,
Vero

El lun, 7 jun 2021 a las 3:34, Vaclav Petras ()
escribió:

> The word "branch" in "previewbranch_8_0" seems superfluous to me as it
> does in releasebranch_7_8 plus it is two words together without a
> separator. Would v8 be a good time to change that practice?
>
> Advantages of just release_8_0:
>
> A1) No 'branch == releasebranch_7_8' or 'switch to the releasebranch_7_8
> branch' statements.
>
> A2) Master branch is also only a branch and does not have the word branch
> in it.
>
> A3) Both QGIS and GDAL use only "release", not "branch", in the name of
> their release branches.
>
> Disadvantages of just release_8_0:
>
> D1) In contexts where you use Git to get a specific branch or tag, you
> don't see from the command that it is indeed a branch (in `git --branch
> release_8_0`, release_8_0 could, in theory, be a tag). However, you are
> likely to correctly guess it is a branch, not a tag, since tags for release
> are most often mostly the numbers only, i.e., in format v8.0 or, as in our
> case, 8.0.
>
> D2) Scripts constructing the branch name from the version name will break,
> however it seems like a better practice to me in this case to parameterize
> the whole branch name and there needs to be likely other changes for v8 in
> these scripts anyway.
>
> Vaclav
>
> On Sun, Jun 6, 2021 at 2:41 AM Markus Neteler  wrote:
>
>> Hi all,
>>
>> The new 8.0.0alpha preview branch is ready:
>>
>> https://github.com/OSGeo/grass/tree/previewbranch_8_0
>>
>> Best,
>> Markus
>> ___
>> 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