Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team

Howard Butler-3
All,

I propose to add Thomas Knudsen and Kristian Evers to the Proj.4 team with commit rights into the OSGeo/Proj.4 repository. They have been leading a modernization effort in the Proj.4 package to improve maintainability, reduce redundancy, and increase test coverage. Thomas has also been a long time Proj.4 list member, and he has provided a lot of experience and guidance on a number of coordinate system and projection topics. Both have been software contributors in a project that has been lacking them, and giving them full access will make it more convenient for them to contribute.

I'll start with a +1.

Howard
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team

support-2
Hello,

Please! "if it works .. don't touch it" -- if you make "huge
improvements" label the whole product something ELSE than Proj.4. and
don't mix it with the stable version!
We don't want to have random rewriters for the code since it does not
add anything but more work for us! (... and lot of random errors and
problems)

Thanks! Janne.

----------------------------------------

Howard Butler kirjoitti 20.05.2016 16:50:

> All,
>
> I propose to add Thomas Knudsen and Kristian Evers to the Proj.4 team
> with commit rights into the OSGeo/Proj.4 repository. They have been
> leading a modernization effort in the Proj.4 package to improve
> maintainability, reduce redundancy, and increase test coverage. Thomas
> has also been a long time Proj.4 list member, and he has provided a
> lot of experience and guidance on a number of coordinate system and
> projection topics. Both have been software contributors in a project
> that has been lacking them, and giving them full access will make it
> more convenient for them to contribute.
>
> I'll start with a +1.
>
> Howard
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj

--
MNS Support
NNS Master Navigator Software
Copyright © Sapper Oy
www.mnspoint.com
[hidden email]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team

Howard Butler-3

> On May 20, 2016, at 9:19 AM, [hidden email] wrote:
>
> Hello,
>
> Please! "if it works .. don't touch it"

Janne,

I'll let them discuss the rationale for their efforts, but I would point out that the converse of your statement is also probably true. "If you don't touch it, it will rot". The two+ years of no Proj.4 releases and backlog of unattended tickets exemplify that. The large ticket backlog is due in part to few people feeling confident enough to make fixes or improvements to the code beyond small tweaks. More confidence is achieved by more automated testing and code pathways that are easier to follow - precisely the types of contributions Thomas and Kristian have been making.

Their improvements will make it much easier for people to come in and work in the codebase. They added a large mass of tests to back up changes and protect against future rot. It is also very likely they have lessened the security venerability surface that Proj.4 was providing, though I have no specific proof of that claim other than to say that less complex code generally means fewer pathways to break into.

> label the whole product something ELSE than Proj.4. and don't mix it with the stable version!


Proj.4 is already a fork, if you'll remember.

> We don't want to have random rewriters for the code since it does not add anything but more work for us! (... and lot of random errors and
> problems)

Do you not have rigorous automated testing to confirm whether or not a new version of a given open source library you are using will cause regressions in your platform? Certainly you use other software beyond Proj.4 that moves much faster than it does, right? There's nothing preventing you from staying with your old(er) version of Proj.4.

Howard


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team

rgreenwood
In reply to this post by support-2
I am not a metacrs nor PROJ.4 PSC member but have worked with PROJ.4 for years. I strongly support the efforts of Thomas Knudsen and Kristian Evers to modernize the code, remove the macros and add test coverage. PROJ.4 needs this to stay relevant, useful and maintainable.

Best regards,
Rich

On Fri, May 20, 2016 at 8:19 AM, <[hidden email]> wrote:
Hello,

Please! "if it works .. don't touch it" -- if you make "huge
improvements" label the whole product something ELSE than Proj.4. and
don't mix it with the stable version!
We don't want to have random rewriters for the code since it does not
add anything but more work for us! (... and lot of random errors and
problems)

Thanks! Janne.

----------------------------------------

Howard Butler kirjoitti 20.05.2016 16:50:
> All,
>
> I propose to add Thomas Knudsen and Kristian Evers to the Proj.4 team
> with commit rights into the OSGeo/Proj.4 repository. They have been
> leading a modernization effort in the Proj.4 package to improve
> maintainability, reduce redundancy, and increase test coverage. Thomas
> has also been a long time Proj.4 list member, and he has provided a
> lot of experience and guidance on a number of coordinate system and
> projection topics. Both have been software contributors in a project
> that has been lacking them, and giving them full access will make it
> more convenient for them to contribute.
>
> I'll start with a +1.
>
> Howard
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj

--
MNS Support
NNS Master Navigator Software
Copyright © Sapper Oy
www.mnspoint.com
[hidden email]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj



--
Richard W. Greenwood, PLS
www.greenwoodmap.com

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team

Thomas Knudsen

Janne,


First, I strongly object to being characterized as a “random rewriter”.


I have used proj since 1993, did my first (tiny) contribution to the code base in 1999, and I facilitated the inclusion of the etmerc, high precision transverse mercator code written by my colleague Karsten Engsager, in 2008.


It is correct that I have not touched the code base since then, but that does not turn me into a “random rewriter”.


Also, I described my intended work, and asked for comments and opinions on the proj mailing list more than a month ago. It attracted one comment, which was very much in favor of the work. It did not attract any comments from you.


Also, the pull request has been open since the beginning of april. Howard Butler, Even Rouault, and Micah Cochran have commented and given constructive criticism. I have seen no comments from you.


So all in all, you have had plenty of time to air your opinion. It would have been very helpful if you had done it a bit earlier than 2 months into the process. As a long term proj-list member, I know that you are a frequent and very helpful list contributor, so I have great respect for your experience and willingness to share it, and I believe you could have been a very helpful commenter and mentor for this work.



Second: In general I agree with your opinion of “not touching what works”.


However, what “works” is not easily definable - especially not in the long term.


Kristian Evers and I have turned to proj after having spent time updating trlib, the transformation system of the Danish national mapping agency (now SDFE, formerly GST, formerly KMS, formerly GI).


trlib originated as Algol code written around 1961, for the GIER system (a, for that time, medium sized computer, which was highly optimized for geodetic computations). The code survived and evolved through more than 5 decades following what was “current best practice” all along.


And the one “best practice” that has been prevalent through all these decades has been exactly the one you forward here.


The problem is that, while commendable for the medium term, for the long term “not touching what works” leads to kludge-upon-kludge, from bolting on additional functionality, while not touching existing code.


In the long term, the “not touching what works” dogma (NTWW in the following) leads to stale and unmaintainable code.


As an example, for trlib, one of the things we have removed during the last few years of code revision, is a complete user-space Virtual Menory mangagement system. It was evidently needed when added to the code around 1970, and left in due to NTWW when the code was migrated from Algol to C around 1980. And kept ever since, due to NTWW.


So our experience is very much that NTWW should be challenged now and then. Things change, and so do the hardware platforms the code is supposed to run on.


The proj.4 macro system reflects a development environment of Tektronix style, green phosphor 24x80 terminals, where saving vertical whitespace directly translated into a better general view, by having more context on screen at a time.


This is not the problem for modern coding tools on modern high-resolution displays. In today’s coding environment the proj internal macro system is a high barrier for entry: It makes it extremely hard for new coders to get productive.


If you look at the commit history, you will notice that new people enter the project in order to contribute one or two new projectione that they need.


They do not stay to help evolving proj further. I hypothesize that this is at least partially because the macro system is convoluted and not at all C-like (e.g. leading to syntax highlighter blues).


My intention was to make the code less impenetrable, in order to make it more welcoming to new contributors. As you will see when you study the code, this has been done without touching the algorithmic flow. The procedure has been designed to enhance the clarity for human readers - not to touch the flow.


I suggest you read the description “A verbose justification for some highly intrusive code surgery” I wrote at the very beginning of this work, over at https://github.com/busstoptaktik/proj.4/blob/sdfe-refactor-macros--and-repair-generic-constructor-bug/src/PJ_minimal.c. Hopefully you will see that I have no intentions to break what works - but at medium time scale intervals, changing what works is necessary in order to keep things in shape.


regards

Thomas



_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team

Thomas Knudsen
Rich,

Thank you for the kind words of support for the work done by Kriatian Evers and myself! Needless to say that I very much agree with your opinion :-)

/Thomas

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Motion: add Kristian Evers and Thomas Knudsen to the Proj.4 team

Thomas Knudsen
In reply to this post by support-2
All,

I apologize for reposting this post from yesterday, but it appears that gmail mangled the outgoing text, turning it into an attachment, making the text invisible on many platforms. Hope it works this time - and please ignore if you've already seen this.

/Thomas

Original post:


Janne,

First, I strongly object to being characterized as a “random rewriter”.

I have used proj since 1993, did my first (tiny) contribution to the code base in 1999, and I facilitated the inclusion of the etmerc, high precision transverse mercator code written by my colleague Karsten Engsager, in 2008.

It is correct that I have not touched the code base since then, but that does not turn me into a “random rewriter”. 

Also, I described my intended work, and asked for comments and opinions on the proj mailing list more than a month ago. It attracted one comment, which was very much in favor of the work. It did not attract any comments from you.

Also, the pull request has been open since the beginning of april. Howard Butler, Even Rouault, and Micah Cochran have commented and given constructive feedback. I have seen no comments from you.

So all in all, you have had plenty of time to air your opinion. It would have been very helpful if you had done it a bit earlier than 2 months into the process. As a long term proj-list member, I know that you are a frequent and very helpful list contributor, so I have great respect for your experience and willingness to share it, and I believe you could have been a very helpful commenter and mentor for this work.


Second: In general I agree with your opinion of “not touching what works”.

However, what “works” is not easily definable - especially not in the long term.

Kristian Evers and I have turned to proj after having spent time updating trlib, the transformation system of the Danish national mapping agency (now SDFE, formerly GST, formerly KMS, formerly GI).

trlib originated as Algol code written around 1961, for the GIER system (a, for that time, medium sized computer, which was highly optimized for geodetic computations). The code survived and evolved through more than 5 decades following what was “current best practice” all along.

And the one “best practice” that has been prevalent through all these decades has been exactly the one you forward here.

The problem is that, while commendable for the medium term, for the long term “not touching what works” leads to kludge-upon-kludge, from bolting on additional functionality, while not touching existing code.

In the long term, the “not touching what works” dogma (NTWW in the following) leads to stale and unmaintainable code.

As an example, for trlib, one of the things we have removed during the last few years of code revision, is a complete user-space Virtual Menory mangagement system. It was evidently needed when added to the code around 1970, and left in due to NTWW when the code was migrated from Algol to C around 1980. And kept ever since, due to NTWW.

So our experience is very much that NTWW should be challenged now and then. Things change, and so do the hardware platforms the code is supposed to run on.

The proj.4 macro system reflects a development environment of Tektronix style, green phosphor 24x80 terminals, where saving vertical whitespace directly translated into a better general view, by having more context on screen at a time.

This is not the problem for modern coding tools on modern high-resolution displays. In today’s coding environment the proj internal macro system is a high barrier for entry: It makes it extremely hard for new coders to get productive.

If you look at the commit history, you will notice that new people enter the project in order to contribute one or two new projections that they need.

They do not stay to help evolving proj further. I hypothesize that this is at least partially because the macro system is convoluted and not at all C-like (e.g. leading to syntax highlighter blues).

My intention was to make the code less impenetrable, in order to make it more welcoming to new contributors. As you will see when you study the code, this has been done without touching the algorithmic flow. The procedure has been designed to enhance the clarity for human readers - not to touch the flow.

I suggest you read the description “A verbose justification for some highly intrusive code surgery” I wrote at the very beginning of this work, over at https://github.com/busstoptaktik/proj.4/blob/sdfe-refactor-macros--and-repair-generic-constructor-bug/src/PJ_minimal.c. Hopefully you will see that I have no intentions to break what works - but at medium time scale intervals, changing what works is necessary in order to keep things in shape.

regards
Thomas


2016-05-20 16:19 GMT+02:00 <[hidden email]>:
Hello,

Please! "if it works .. don't touch it" -- if you make "huge
improvements" label the whole product something ELSE than Proj.4. and
don't mix it with the stable version!
We don't want to have random rewriters for the code since it does not
add anything but more work for us! (... and lot of random errors and
problems)

Thanks! Janne.

----------------------------------------

Howard Butler kirjoitti 20.05.2016 16:50:
> All,
>
> I propose to add Thomas Knudsen and Kristian Evers to the Proj.4 team
> with commit rights into the OSGeo/Proj.4 repository. They have been
> leading a modernization effort in the Proj.4 package to improve
> maintainability, reduce redundancy, and increase test coverage. Thomas
> has also been a long time Proj.4 list member, and he has provided a
> lot of experience and guidance on a number of coordinate system and
> projection topics. Both have been software contributors in a project
> that has been lacking them, and giving them full access will make it
> more convenient for them to contribute.
>
> I'll start with a +1.
>
> Howard
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj

--
MNS Support
NNS Master Navigator Software
Copyright © Sapper Oy
www.mnspoint.com
[hidden email]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj