Re: [GRASS-dev] Should we use GitHub Discussions?

[Stefan Blumentrath]

Hi,

Personally, I tried being active on StackExchange. However, even though I do 
like to support colleagues using GRASS and the project in general, the GIS SE 
system somehow put me off. I just did not like the attitude there and would 
myself not even think about asking questions there...

That said, GitHub discussions can be different. But I still would very much 
prefer the mentioned option to "modernize" the ML system.

I also think that if people could register at OSGeo (and MLs) with other 
accounts (Github, Google, ...) that could lower entrance barriers. But that is 
a different, and probably more complicated (?) issue...

Cheers
Stefan

From: grass-dev  On Behalf Of Vaclav Petras
Sent: onsdag 10. februar 2021 04:10
To: Markus Neteler 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] Should we use GitHub Discussions?



On Tue, Feb 9, 2021 at 3:59 PM Markus Neteler 
mailto:nete...@osgeo.org>> wrote:
On Tue, Feb 9, 2021 at 9:50 PM Vaclav Petras 
mailto:wenzesl...@gmail.com>> wrote:
> On Tue, Feb 9, 2021 at 4:01 AM Markus Neteler 
> mailto:nete...@osgeo.org>> wrote:
>>
> If we had a presence on StackExchange like QGIS has, we wouldn't be having a 
> discussion about GitHub Discussions in the first place.

Try this:

https://gis.stackexchange.com/questions/tagged/grass
--> 2,027 questions

I wish this would indicate a healthy community and I wish we would have one 
there. However, with a small sample from questions with recent activity, I see 
only a couple of users answering (2 or so; BTW thanks! you know who you are) 
and from the 2027 questions tagged grass, there are "475 questions with no 
upvoted or accepted answers" [1]. This does not sound like what is in the 
original Nyall's email against QGIS using GitHub Discussions which says 
"there's LOTS of informed users answering all the QGIS questions on 
gis.stackexchange." [2]. Perhaps even more telling is that no one except myself 
[3] mentioned GIS StackExchange in this discussion up until now.

[1] 
https://gis.stackexchange.com/questions/tagged/grass?tab=Unanswered
[2] 
https://lists.osgeo.org/pipermail/qgis-psc/2021-February/009244.html
[3] 
https://lists.osgeo.org/pipermail/grass-dev/2021-January/094867.html

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

Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

[Nicklas Larsson via grass-dev]

 Markus,

Thanks for the historical background on C and GRASS GIS, it sure has its place 
in this context!

That grand job on formalising the code, did indeed pay-off! Today we only need 
to decide what standard to use in the future.
Still compiles without problems.
Still no need for major (or any really) changes, language wise.
Only the compilers of today are perhaps better to identify weak spots.


Nicklas
 On Wednesday, 10 February 2021, 14:27:48 CET, Markus Neteler 
 wrote:  
 
 Hi Nicklas, all,

Thanks for the summary and pushing things forward!

Just one addition, for the sake of completeness:

On Wed, Feb 10, 2021 at 1:16 PM Nicklas Larsson via grass-dev
 wrote:
>
> First of all, thank you all for your feedback and contribution to this topic. 
> I think it is really important to clearly state the "rules of the game" for 
> going forward.
>
> Let me try summarise the need for this:
>
...
> - G7 has seen the transition from Python 2 to 3 [1]. Going forward, a final 
> (official and unambiguous) dot for Python 2 need to be put with a statement 
> of minimum support of a Python 3 version.

There was another big transition in the past, being worked on, if I
recall correctly, from 2002 onwards (we started discussions in
ITC-irst with Prof Giulio Antoniol) and implemented the final result
after many discussions in the repo in Januar 2006:

Source code conversion of K C notation to ANSI C, modifying almost
all GRASS GIS files:
- 
[details](https://lists.osgeo.org/pipermail/grass-dev/2006-January/020767.html)
- [scientific 
article](http://www.antoniol.net/wp-content/papercite-data/pdf/2006/04021333.pdf):
A Feedback Based Quality Assessment to Support Open Source Software
Evolution: the GRASS Case Study,22nd IEEE International Conference on
Software Maintenance (ICSM'2006),
- related source code changes:
    - [r18618](https://trac.osgeo.org/grass/changeset/18618),
    - [r18619](https://trac.osgeo.org/grass/changeset/18619),
    - [r18623](https://trac.osgeo.org/grass/changeset/18623),
    - [r18625](https://trac.osgeo.org/grass/changeset/18625),
    - [r18626](https://trac.osgeo.org/grass/changeset/18626),
    - [r18627](https://trac.osgeo.org/grass/changeset/18627),
    - [r18628](https://trac.osgeo.org/grass/changeset/18628),
    - [r18632](https://trac.osgeo.org/grass/changeset/18632),
    - [r18633](https://trac.osgeo.org/grass/changeset/18633)

It was a massive C change as you can see which we managed to generate
by eventually automating most of the conversion/update tasks.
We worked with Prof Antoniol and his team for a long time on this
topic and it was definitely worth it!

Best,
Markus

Other related references:
* Di Penta, M., M. Neteler, G. Antoniol, E. Merlo, 2005: A
Language-Independent Software Renovation Framework. Journal of Systems
and Software, 77(3), pp. 225-240. (IF 2005: 0.744),
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.4762=rep1=pdf
* Antoniol, G., M. Di Penta, and M. Neteler, 2003. Moving to smaller
libraries via clustering and genetic algorithms. In CSMR 2003, 7th
IEEE European Conference on Software Maintenance and Reengineering,
Proc. IEEE Computer Society, 307-316,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.58.988=rep1=pdf
* Di Penta, M. Neteler, G. Antoniol and E. Merlo, 2002. Knowledge
Based Library Refactoring for an Open Source Project. IEEE Working
Conference on Reverse Engineering WCRE, Oct. 28 – Nov. 1, Richmond,
Virginia, USA. Proc. IEEE Computer Society, pp. 319-328.,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.4.4165=rep1=pdf

-- 
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://courses.neteler.org/blog
  ___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

[Markus Neteler]

Hi Nicklas, all,

Thanks for the summary and pushing things forward!

Just one addition, for the sake of completeness:

On Wed, Feb 10, 2021 at 1:16 PM Nicklas Larsson via grass-dev
 wrote:
>
> First of all, thank you all for your feedback and contribution to this topic. 
> I think it is really important to clearly state the "rules of the game" for 
> going forward.
>
> Let me try summarise the need for this:
>
...
> - G7 has seen the transition from Python 2 to 3 [1]. Going forward, a final 
> (official and unambiguous) dot for Python 2 need to be put with a statement 
> of minimum support of a Python 3 version.

There was another big transition in the past, being worked on, if I
recall correctly, from 2002 onwards (we started discussions in
ITC-irst with Prof Giulio Antoniol) and implemented the final result
after many discussions in the repo in Januar 2006:

Source code conversion of K C notation to ANSI C, modifying almost
all GRASS GIS files:
- 
[details](https://lists.osgeo.org/pipermail/grass-dev/2006-January/020767.html)
- [scientific 
article](http://www.antoniol.net/wp-content/papercite-data/pdf/2006/04021333.pdf):
A Feedback Based Quality Assessment to Support Open Source Software
Evolution: the GRASS Case Study,22nd IEEE International Conference on
Software Maintenance (ICSM'2006),
- related source code changes:
- [r18618](https://trac.osgeo.org/grass/changeset/18618),
- [r18619](https://trac.osgeo.org/grass/changeset/18619),
- [r18623](https://trac.osgeo.org/grass/changeset/18623),
- [r18625](https://trac.osgeo.org/grass/changeset/18625),
- [r18626](https://trac.osgeo.org/grass/changeset/18626),
- [r18627](https://trac.osgeo.org/grass/changeset/18627),
- [r18628](https://trac.osgeo.org/grass/changeset/18628),
- [r18632](https://trac.osgeo.org/grass/changeset/18632),
- [r18633](https://trac.osgeo.org/grass/changeset/18633)

It was a massive C change as you can see which we managed to generate
by eventually automating most of the conversion/update tasks.
We worked with Prof Antoniol and his team for a long time on this
topic and it was definitely worth it!

Best,
Markus

Other related references:
* Di Penta, M., M. Neteler, G. Antoniol, E. Merlo, 2005: A
Language-Independent Software Renovation Framework. Journal of Systems
and Software, 77(3), pp. 225-240. (IF 2005: 0.744),
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.4762=rep1=pdf
* Antoniol, G., M. Di Penta, and M. Neteler, 2003. Moving to smaller
libraries via clustering and genetic algorithms. In CSMR 2003, 7th
IEEE European Conference on Software Maintenance and Reengineering,
Proc. IEEE Computer Society, 307-316,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.58.988=rep1=pdf
* Di Penta, M. Neteler, G. Antoniol and E. Merlo, 2002. Knowledge
Based Library Refactoring for an Open Source Project. IEEE Working
Conference on Reverse Engineering WCRE, Oct. 28 – Nov. 1, Richmond,
Virginia, USA. Proc. IEEE Computer Society, pp. 319-328.,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.4.4165=rep1=pdf

-- 
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://courses.neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

[Nicklas Larsson via grass-dev]

 First of all, thank you all for your feedback and contribution to this topic. 
I think it is really important to clearly state the "rules of the game" for 
going forward.

Let me try summarise the need for this:

- There is no official, clear statement on C standard support for the project
- The implicit understanding of adherence to C89/C90 is no longer correct, as 
the code base contains C99 additions.
- Newer C standards (C99 and later) may provide better cross platform support 
and safer code.
- G7 has seen the transition from Python 2 to 3 [1]. Going forward, a final 
(official and unambiguous) dot for Python 2 need to be put with a statement of 
minimum support of a Python 3 version.
- Only a small part of the code base is consists of C++ [2]. To the best of my 
knowledge there in not even an implicit understanding/agreement on standard 
support.
- Platform and compiler support of the standards has improved notably in recent 
years.


What are the consequences/benefits:
- Contributors will know what is allowed or not.
- It is possible to "guard" against using too new language features (esp. for C 
and C++) or using too old features (esp. Python). In this respect we're setting 
a max support for C/C++, and min support for Python.
- Existing C and C++ code compiles also with C17 and C++17, and will **not** 
have to be changed as a consequence of standard support policy.
- Old Python code may be discarded.


I think Anna's suggestion to look at how GDAL is handling the question on 
Python with a long term strategy is a good way to go, but we need to consider 
GRASS has a different release schedule.
(I personally believe 3.6 is too conservative for G8. When the moment comes for 
G8 release, I suspect 3.6 is close to if not past end-of-life.)


It would be most favourable for all contributors and the project if the 
community could come to an agreement on this topic. I see no reason to postpone 
a decision on this much longer.

The final word on this need to be that of the PSC's. Whether through simple 
vote or a RFC. However, a sounding of the opinion of the dev-community on this 
matter is of equal importance and can be of help for the PSC.


May I propose setting the programming language standard support for the GRASS 
GIS 8:

PROPOSAL:
=

- Python 3.6

- C11 with core (mandatory) features
 (optional features may be used if availability is tested with macro,
 and if not supported, alternative fallback code must be provided [3])

- C++11


Best,
Nicklas



[1] That must have been a h*** of a job! Respect!
[2] 4 core and 3 add-on modules.
[3] See 
 for short summary of C11 and list of its optional features.



 On Tuesday, 9 February 2021, 22:29:49 CET, Markus Metz 
 wrote:  
 
 Just for clarification,
C code written for an older C standard works fine with newer C standards.

This is different with Python: code written for a previous Python version might 
no longer work with a newer Python version. 
Increasing the C standard for existing GRASS C code is safe, it will still 
compile and work.

Increasing the Python version is not safe because existing GRASS Python code 
might not be compatible with newer Python versions, thus the need for a minimum 
required Python version.
Markus M

On Sun, Feb 7, 2021 at 10:36 PM Markus Metz  
wrote:
>
>
>
> On Sun, Feb 7, 2021 at 4:07 PM Moritz Lennert  
> wrote:
> >
> >
> >
> > Am 7. Februar 2021 05:01:38 MEZ schrieb "Anna Petrášová" 
> > :
> > >On Wed, Feb 3, 2021 at 2:47 PM Anna Petrášová  
> > >wrote:
> > >
> > >>
> > >>
> > >> On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson 
> > >> wrote:
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová <
> > >>> kratocha...@gmail.com> wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Thu, Jan 28, 2021 at 4:28 AM Nicklas Larsson via grass-dev <
> > >>> grass-dev@lists.osgeo.org> wrote:
> > >>> > Dear Devs!
> > >>> >
> > >>> > As a relatively new member of the GRASS GIS dev community, I have had
> > >>> to search for information on mailing lists, old trac comments etc.
> > >>> regarding coding practice and in particular minimum programming language
> > >>> standard support. Ending up in not entirely conclusive understanding. Up
> > >>> until now, I have been mostly involved in Python development and I’m 
> > >>> still
> > >>> not absolutely certain, although I assume 3.5 is minimum version. And 
> > >>> I’m
> > >>> not alone, see e.g. [1].
> > >>> >
> > >>> > Now, I’ve encountered a similar dilemma with C standard support,
> > >>> attempting to address compiler warnings [2], in particular with the PR
> > >>> #1256 [3].
> > >>> >
> > >>> > I would be great if there were a (one) place where the min support of
> > >>> Python version, C (C89, C99, C11, C17…) and C++ (C++03, C++11, C++14 …)
> > >>> standard is stated -- loud and clear. Obviously, there has to be a
> > >>> consensus