Date   

Re: Find some consensus

Paul Bender
 




On Jul 20, 2020, at 3:44 PM, Pete Cressman <pete_cressman@...> wrote:

In the past I often felt that the PR reviews were authoritarian enforcement of an ever expanding set of rules.  Even though at the time I knew they were not intended that way, I could not escape the impression these arbitrary requirements had to be met in order to get my code merged.

In fairness, there were several occasions when the reviews pointed out things that improved the quality of my code.  However, more frequently, they often were expressions of style and preference.

I want to get away from that style and preference nitpicking.  To the extent that I may have been to blame for some of that, I apologize.

My rule of thumb, something I tried to instill in my students when I was teaching, was that you have to make it work first, then you can make it pretty.

( one of my coworkers expresses the same idea as “working, right, fast”,  which means make it work, the make it stylistically correct, and lastly look at efficiency).

But now, times have changed, I'm afraid the joys of 'code wins' are gone when JMRI was a playground to experiment with ideas and get the reactions of users in cycles of response and request.

This is absolutely not what I want to hear in this thread.  I still think there is a lot of room to play with new ideas.

We don’t want to break existing code, but I still think we want to encourage developers ( new and old ) with new ideas.  This is how we grow to meet the future needs of model railroaders.

As an example, Daniel with his Analog and Digital IO classes has found a way to introduce a pair of new object types into the system.  Will they result in any new hardware types or new uses?  It is hard to say right now, but the idea is now out there and we should encourage its growth.

Some of us old timers here may have lost sight of that, and this thread has really brought that into focus for me.

Now JMRI is a brand, a product, that must meet the quality expectations of other brands and products; i.e. the NMRA, Kalmbach Media, Model Railroad manufacturers and a huge user community.

While all this is true, JMRI is also how some of us spend some or all of our hobby time.  It is our way of giving back to the community.

Paul


Re: Surveying users on use of help/web #WebHelpUpdate

JerryG
 

Over 180 responses to date.


Re: Any restriction on network in jython scripts?

emmanuel ALLAUD
 

Hi,
I want to do something very simple: the jython script will implement a server to which "real" python scripts connnect, these will handle the bus of devices (the plan is arduino on rs485 with a special protocol I already talked about).
The jython script will just be in charge of sending things like "AT1:23,1" meaning throw turnout 23 on node 1, and setting sensors from messages received via the client's connections.
Basically I need sockets, select, strings and dictionaries.
Thanks,
Manu

Le lun. 20 juil. 2020 à 21:35, Balazs Racz <balazs.racz@...> a écrit :
You can transliterate java into python. So you can definitely create java servers from python and make them call back to you into your python class. You can also implement a java interface (such as Runnable) with a python class and pass that into a function call on a java object from your python script.

On Mon, Jul 20, 2020 at 9:06 PM emmanuel ALLAUD <eallaud@...> wrote:
Ok I'll just try and keep my fingers crossed.
Thanks
Manu

Le lun. 20 juil. 2020 à 20:35, Randall Wood via groups.io <rhwood=mac.com@groups.io> a écrit :
Those will either “just work” or not work at all. You can only python modules that have no native code dependencies (i.e. are “pure Python”) or have been provided by the Jython runtime. I don’t know if those two modules are pure Python or have or have not been provided by the Jython project.

Randall
> On Jul 20, 2020, at 11:43, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> I would like to use a jython script which implements a small server on. Is is possible to import socket and select in jython?
>
> TIA
>
> Manu
>
>
>
>




Re: Find some consensus

Pete Cressman
 

I wish to add my gratitude for all the work Bob has done for us over the years. He was always tolerant of my ignorance and ineptitude and was kind when offering corrective advise. My regret is for taking too much of his time on things I should have figured out for myself. For this I sincerely apologize.

On the matter of consensus, I support Paul's list.

In the past I often felt that the PR reviews were authoritarian enforcement of an ever expanding set of rules.  Even though at the time I knew they were not intended that way, I could not escape the impression these arbitrary requirements had to be met in order to get my code merged.

In fairness, there were several occasions when the reviews pointed out things that improved the quality of my code.  However, more frequently, they often were expressions of style and preference.

But now, times have changed, I'm afraid the joys of 'code wins' are gone when JMRI was a playground to experiment with ideas and get the reactions of users in cycles of response and request.

Now JMRI is a brand, a product, that must meet the quality expectations of other brands and products; i.e. the NMRA, Kalmbach Media, Model Railroad manufacturers and a huge user community.

So I definitely support the use of peer review of PR's and I will pay much closer attention to the links under the 'Techniques and Standards' sidebar on the Developers page. But I think I will restrict my efforts to the repair and improvement of the current feature set.

Best Regards,
Pete Cressman


Re: Any restriction on network in jython scripts?

Balazs Racz
 

You can transliterate java into python. So you can definitely create java servers from python and make them call back to you into your python class. You can also implement a java interface (such as Runnable) with a python class and pass that into a function call on a java object from your python script.


On Mon, Jul 20, 2020 at 9:06 PM emmanuel ALLAUD <eallaud@...> wrote:
Ok I'll just try and keep my fingers crossed.
Thanks
Manu

Le lun. 20 juil. 2020 à 20:35, Randall Wood via groups.io <rhwood=mac.com@groups.io> a écrit :
Those will either “just work” or not work at all. You can only python modules that have no native code dependencies (i.e. are “pure Python”) or have been provided by the Jython runtime. I don’t know if those two modules are pure Python or have or have not been provided by the Jython project.

Randall
> On Jul 20, 2020, at 11:43, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> I would like to use a jython script which implements a small server on. Is is possible to import socket and select in jython?
>
> TIA
>
> Manu
>
>
>
>




Re: Any restriction on network in jython scripts?

emmanuel ALLAUD
 

Ok I'll just try and keep my fingers crossed.
Thanks
Manu

Le lun. 20 juil. 2020 à 20:35, Randall Wood via groups.io <rhwood=mac.com@groups.io> a écrit :
Those will either “just work” or not work at all. You can only python modules that have no native code dependencies (i.e. are “pure Python”) or have been provided by the Jython runtime. I don’t know if those two modules are pure Python or have or have not been provided by the Jython project.

Randall
> On Jul 20, 2020, at 11:43, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> I would like to use a jython script which implements a small server on. Is is possible to import socket and select in jython?
>
> TIA
>
> Manu
>
>
>
>




Re: Any restriction on network in jython scripts?

Randall Wood <rhwood@...>
 

Those will either “just work” or not work at all. You can only python modules that have no native code dependencies (i.e. are “pure Python”) or have been provided by the Jython runtime. I don’t know if those two modules are pure Python or have or have not been provided by the Jython project.

Randall

On Jul 20, 2020, at 11:43, emmanuel ALLAUD <eallaud@...> wrote:

Hi all,

I would like to use a jython script which implements a small server on. Is is possible to import socket and select in jython?

TIA

Manu




Any restriction on network in jython scripts?

emmanuel ALLAUD
 

Hi all,

I would like to use a jython script which implements a small server on. Is is possible to import socket and select in jython?

TIA

Manu


Re: Find some consensus

danielb987
 

2020-07-20 11:53 skrev Andrew Crosland:
- I am a believer in testing and test-cases - my career has convinced me of the benefits. I strongly support the goal of resolving the "unstable" testcases, and would help if I had a clue of the common failure-modes and their common solutions, at least for those parts of the code where I feel that I have some strong level of experience.
This is another area where expertise counts. I am keen to write good
test cases but suffer from the "I'll do it later when the code is
working" attitude. Having CI mandatory tests for every class is a good
thing. I will often cut, paste and adapt code from a similar test
class. In doing so I do sometimes feel others are sometimes as guilty
as me in writing only the most basic test class to call the
constructor and not revisiting later. In my case I think I need a
deeper understanding of unit testing and how to write good test cases,
e.g. knowing what facilities for available running/monitoring tests
and loggong results. Is there a good primer for Junit (is that what we
use now) and how to monitor test results and log the them?
Some thoughts about testing:

I start with writing tests for small simple methods. It's often easier to write tests for simple methods than complex ones, it gives me experience of writing tests, and by making the simple parts less fragile, the more complex parts gets less fragile as a result. (If the bricks fall apart, the house will fall apart).


I find it very useful to look at the coverage. For example, I run:

mvn test -Dtest="jmri.jmrit.beantable.LogixNGTableActionTest,jmri.jmrit.logixng.**.*Test"

to test my code and then run:

ant coveragereport

to generate the coverage report. That creates the folder "coveragereport" with one sub folder for each package in JMRI. For example, the file "coveragereport/jmri/Conditional.html" shows the coverage of the class jmri.Conditional.

The coverage report lets me see which parts of the code that already have tests and which parts that don't.


If the code has some constant values that are important, for example:

public final static int TURNOUT_THROWN = 2;
public final static int TURNOUT_CLOSED = 4;

I write tests that tests the values of these to prevent that these values are changed by misstake. See the class jmri.ConditionalTest as an example of that. I do that for constants that must stay constant over time, for example if the value is stored to XML files or used in communication with a microcontroller. This has the effect that if somebode really wants to change these constants, they have to change the constant in two places and therefore are forced to think a second time of what they are doing.


And last but not least:
Every single test counts! I did some work on writing coverage on Logix, mostly testing small simple methods in the Logix classes. That work got far from complete, but at least the Logix code is less fragile now than it was before.

Daniel


Re: Find some consensus

danielb987
 

Thanks. Please add links to the Javadoc of Jemmy. The link "Jemmy Javadoc" in the section "Using Jemmy" doesn't seem to work.

Daniel

2020-07-20 14:53 skrev Paul Bender:

We have some documentation on testing JMRI (
https://www.jmri.org/help/en/html/doc/Technical/JUnit.shtml [1] ) but
I just skimmed through it and it is outdated due to the change to
JUnit 5.
I’ll work on updating that today, and see if I can find some good
tutorials on testing in general to add as links.
Paul
Links:
------
[1] https://www.jmri.org/help/en/html/doc/Technical/JUnit.shtml#writeAddl4ExistClass
[2] https://jmri-developers.groups.io/g/jmri/message/3958
[3] https://groups.io/mt/75535614/1303822
[4] https://jmri-developers.groups.io/g/jmri/post
[5] https://jmri-developers.groups.io/g/jmri/editsub/1303822
[6] https://jmri-developers.groups.io/g/jmri/leave/defanged


Re: Find some consensus

Paul Bender
 


On Jul 20, 2020, at 5:54 AM, Andrew Crosland <andrew@...> wrote:
In my case I think I need a deeper understanding of unit testing and how to write good test cases, e.g. knowing what facilities for available running/monitoring tests and loggong results. Is there a good primer for Junit (is that what we use now) and how to monitor test results and log the them?

We have some documentation on testing JMRI ( https://www.jmri.org/help/en/html/doc/Technical/JUnit.shtml ) but I just skimmed through it and it is outdated due to the change to JUnit 5.  

I’ll work on updating that today, and see if I can find some good tutorials on testing in general to add as links.

Paul


Re: Find some consensus

Klaus Killinger
 

I would also like to agree to the list. Good comments have now made the list even better and more precise.

#2 is important because of the high importance of #1.
Could the new release methodology ( https://github.com/JMRI/JMRI/issues/8831 ) be a load reduction? Less releases to build, less load?

I think that #3 becomes easier over time as #4 improves.

Klaus


Am 19.07.2020 um 23:44 schrieb Steve Todd:

On Sat, Jul 18, 2020 at 07:43 PM, Paul Bender wrote:

1) Bob is really the center of this project for most of us, and we'd like
to keep it that way
2) We want to find ways we can reduce Bob's load.
3) Reviews on pull requests are good, but people are indifferent about
requiring them.
4) Testing is good, lets keep doing that, but let's work on the
reliability.
5) Most of us just want to continue making good contributions to JMRI.
6) Perhaps we need to work on our team communication skills.


Re: Find some consensus

Andrew Crosland
 

------ Original Message ------
From: "Bob M." <jawhugrps@...>
To: jmri@jmri-developers.groups.io
Sent: 20/07/2020 01:52:42
Subject: Re: [jmri-developers] Find some consensus

- Like many other JMRI contributors, I am _not_ a programmer by trade or training. I have little knowledge of many of the formal techniques, procedures and terms of modern programming. It seems futile for me to weigh-in on procedures and policies with respect to things like test methodologies or documentation mechanisms or deprecation strategies. I place my trust in those with the appropriate backgrounds to propose, discuss, and implement the policies and procedures and support scripts and web configuration and... And I view it as my personal responsibility to study as needed to make proper use of those mechanisms, polcies and procedures, to the best of my abilities.
I am in 100% agreement here. Hardware and low level firmware are really my thing. I have had exposure to numerous languages and methodologies over the years but never enough to become an expert.

- I am a believer in testing and test-cases - my career has convinced me of the benefits. I strongly support the goal of resolving the "unstable" testcases, and would help if I had a clue of the common failure-modes and their common solutions, at least for those parts of the code where I feel that I have some strong level of experience.
This is another area where expertise counts. I am keen to write good test cases but suffer from the "I'll do it later when the code is working" attitude. Having CI mandatory tests for every class is a good thing. I will often cut, paste and adapt code from a similar test class. In doing so I do sometimes feel others are sometimes as guilty as me in writing only the most basic test class to call the constructor and not revisiting later. In my case I think I need a deeper understanding of unit testing and how to write good test cases, e.g. knowing what facilities for available running/monitoring tests and loggong results. Is there a good primer for Junit (is that what we use now) and how to monitor test results and log the them?

Andrew




--
Andrew Crosland


Re: Find some consensus

Andrew Crosland
 


------ Original Message ------
From: "Steve Todd" <mstevetodd@...>
Sent: 19/07/2020 22:44:34
Subject: Re: [jmri-developers] Find some consensus

The reality is that JMRI is an extremely complex entity, and very few of us have the ability (or the time) to grasp more than an isolated segment at a time. 
This is certainly where I struggle. Randall was very helpful recently when I needed to make some changes outside my own area of knowledge where I could have made a few blunders by not realising the subtleties of what was going on.

Somehow, we need to be more accepting of "good, but not perfect" changes which help contributors feel valued. A little grace goes a long way.

In general I think this is the case, is it not? I know my own code is not perfect :)

Andrew


--
Andrew Crosland


Re: Restart Travis for other developers PRs?

Paul Bender
 

On 7/20/20 12:14 AM, danielb987 wrote:
If I see a PR where Travis has failed and I think that the failure is
not related to the PR itself, should I restart it or let the author of
the PR restart it?

One example is PR #8850 where Travis Headless has failed due to
LoadAndStoreTest. Should I restart that PR and leave a note about why
in the PR, or wait and let the author restart it?
Yes, please do restart failed builds If you can determine why the
failure occurred.

Just make sure you add a comment on the PR that includes what failed.

Paul


Restart Travis for other developers PRs?

danielb987
 

If I see a PR where Travis has failed and I think that the failure is not related to the PR itself, should I restart it or let the author of the PR restart it?

One example is PR #8850 where Travis Headless has failed due to LoadAndStoreTest. Should I restart that PR and leave a note about why in the PR, or wait and let the author restart it?

Daniel


Re: Find some consensus

Bob M.
 

I agree in general with Paul's summary points.

A few comments:

- On pull-request reviews: It seems to me that the various JMRI parts generally have one or more "person of expertise" or one or more "person of deep JMRI coding experience". And some concepts perhaps have one or more persons with "deep experience" - I'm thinking of things like certain coding practices. But noone "knows it all", and few JMRI contributors truely know the mapping of concept-to-expert. While github's mechanisms can try to propose reviewers when a pull request is submitted, it might make sense to maintain and publish a list of various JMRI concepts/systems/implementations and the associated "person(s) of expertise". I know that such a list would have influenced "reviewer" choice on some of my past P/Rs! **Perhaps discussion of this idea needs to be taken to a new thread.**

- Like many other JMRI contributors, I am _not_ a programmer by trade or training. I have little knowledge of many of the formal techniques, procedures and terms of modern programming. It seems futile for me to weigh-in on procedures and policies with respect to things like test methodologies or documentation mechanisms or deprecation strategies. I place my trust in those with the appropriate backgrounds to propose, discuss, and implement the policies and procedures and support scripts and web configuration and... And I view it as my personal responsibility to study as needed to make proper use of those mechanisms, polcies and procedures, to the best of my abilities.

- I am a believer in testing and test-cases - my career has convinced me of the benefits. I strongly support the goal of resolving the "unstable" testcases, and would help if I had a clue of the common failure-modes and their common solutions, at least for those parts of the code where I feel that I have some strong level of experience.

- I will do what I can to help make JMRI better, within those limitations and opportunities which circumstance present to me.

Regards,
Bob M.


Re: Find some consensus

danielb987
 

I fully agree on what you write.

About peer review:

I think it may work, but it requires that people are willing to do peer review, even on parts they don't fully understand. There are parts that only one or a couple of people fully understand and if peer review would require full knowledge, development of these parts would be almost impossible.

But if we all are allowed to do peer review even if we don't fully understands the code, I think it may work. And if I'm uncertain, I can wait a day or two to see if someone else do a peer review, and if not, I can do it.

If we all can do peer reviews, and nobody can veto a PR, we can get around the harshest voice. If you create a PR and I disagree with it and do a bad review, but Paul Bender does his review and approves it, the PR can be merged.

I think it's important that nobody has the right to veto a PR for this to work.

Daniel

2020-07-19 23:44 skrev Steve Todd:

On Sat, Jul 18, 2020 at 07:43 PM, Paul Bender wrote:

1) Bob is really the center of this project for most of us, and we'd
like to keep it that way
2) We want to find ways we can reduce Bob's load.
3) Reviews on pull requests are good, but people are indifferent
about requiring them.
4) Testing is good, lets keep doing that, but let's work on the
reliability.
5) Most of us just want to continue making good contributions to
JMRI.
6) Perhaps we need to work on our team communication skills.
This is a good list, I agree completely with all points, except #3.
On #3, "indifferent" doesn't describe my take.
I DO completely agree with the need for some sort of "peer review",
but I'm very concerned how that will work, given some of the
"communication issues" and "lack of empathy" mentioned.
This seems to be a critical change, much-needed to keep BobJ from
shouldering all of the burden, but simply spreading the same
disagreements around to more people is not a solution.
Without structure, I fear the harshest voices will "win" and the
project will "lose", every time.
The reality is that JMRI is an extremely complex entity, and very few
of us have the ability (or the time) to grasp more than an isolated
segment at a time.
Somehow, we need to be more accepting of "good, but not perfect"
changes which help contributors feel valued. A little grace goes a
long way.
And #1 should be bolded, large font, emphasized, whatever, to make it
clear how important BobJ is to the past, present and future of this
project. He's the only reason I'm still involved, and I doubt I'm the
only person who feels that way.
--SteveT
Links:
------
[1] https://jmri-developers.groups.io/g/jmri/message/3950
[2] https://groups.io/mt/75535614/1303822
[3] https://jmri-developers.groups.io/g/jmri/post
[4] https://jmri-developers.groups.io/g/jmri/editsub/1303822
[5] https://jmri-developers.groups.io/g/jmri/leave/defanged


Re: Find some consensus

Steve Todd
 

On Sat, Jul 18, 2020 at 07:43 PM, Paul Bender wrote:
1) Bob is really the center of this project for most of us, and we'd like to keep it that way
2) We want to find ways we can reduce Bob's load. 
3) Reviews on pull requests are good, but people are indifferent about requiring them.
4) Testing is good, lets keep doing that, but let's work on the reliability.
5) Most of us just want to continue making good contributions to JMRI.
6) Perhaps we need to work on our team communication skills.
This is a good list, I agree completely with all points, except #3.
On #3, "indifferent" doesn't describe my take.
I DO completely agree with the need for some sort of "peer review", but I'm very concerned how that will work, given some of the "communication issues" and "lack of empathy" mentioned.
This seems to be a critical change, much-needed to keep BobJ from shouldering all of the burden, but simply spreading the same disagreements around to more people is not a solution.
Without structure, I fear the harshest voices will "win" and the project will "lose", every time.
The reality is that JMRI is an extremely complex entity, and very few of us have the ability (or the time) to grasp more than an isolated segment at a time.
Somehow, we need to be more accepting of "good, but not perfect" changes which help contributors feel valued. A little grace goes a long way.

And #1 should be bolded, large font, emphasized, whatever, to make it clear how important BobJ is to the past, present and future of this project. He's the only reason I'm still involved, and I doubt I'm the only person who feels that way.

--SteveT


Re: Find some consensus

danielb987
 

2020-07-19 04:43 skrev Paul Bender:
Now, to summarize the rest of what I'm hearing in this thread (just to
play it back, not to add any commentary)
1) Bob is really the center of this project for most of us, and we'd
like to keep it that way
2) We want to find ways we can reduce Bob's load. 
3) Reviews on pull requests are good, but people are indifferent about
requiring them.
4) Testing is good, lets keep doing that, but let's work on the reliability.
5) Most of us just want to continue making good contributions to JMRI.
6) Perhaps we need to work on our team communication skills.
Does that sum up the conversation so far?  Anything to add to the list?
Yes, I think so.

Daniel