Date   

Re: Find some consensus

Bob M.
 

My personal opinions on "vetoing" a P/R:

The JMRI project is fortunate that it has several active developers who are
experts in certain areas of JMRI functionality. I think we ought to make
use of that expertise.

 I think that a "subject expert" should _always_ have the authority to veto
a P/R for reasons which directly relate any of his areas of expertise.

And I think that the project owner, and _perhaps_ the "Maintainers" should
have the ability to overrule any veto. (Having Maintainers as possible
"final judges" would help reduce the administrivia burden which Bob J.
faces.)

Are there GitHub mechanisms available to suppor this concept? I have no
idea. Would we need GitHub mechanisms to implement this methodology?
Perhaps. Perhaps not. We've got along thus far on the "gentleman's
agreement" principle.

Regards,
Bob M.


Re: Outdated Link to SourceForge?

Steve Todd
 

Is the statement 
"SourceForge.net provides project support:"
still valid? If not, I think it should be reworded or removed to prevent confusion.


Re: Find some consensus

danielb987
 

2020-07-21 07:55 skrev Paul Bender:
I think it's important that nobody has the right to veto a PR for this to work.
The mechanics of this may not work, at least not using the built in tools.
I think we need to have a plan on how to handle disagreements. If someone creates a PR and I disagree with it and do a bad review, but several others believe that this PR should be merged anyway, there should be a way for the group to override my judgement.

One way to do that could be that if a PR has a bad review that veto the PR, but two other reviewers approves the PR, the author or one of the reviewers could request that one of the maintainers of JMRI merges the PR despite the bad review. If there are two or three maintainers that always could merge a PR despite a bad review, and the group knows who the maintainers are, that could work.

I think it's reasonable that Bob Jacobsen has the right to veto and I believe most of the group agrees with that, but I think no one else except Bob should have veto and I think it's important to have that clearly expressed. And if the group thinks that Bob J should have right to veto, I think that should also be clearly expressed.

Daniel


Re: Outdated Link to SourceForge?

Randall Wood <rhwood@...>
 

Those pages are linked there to provide a history prior to our move to GitHub. I think they can be retained.

Randall

On Jul 21, 2020, at 14:50, Steve Todd <mstevetodd@...> wrote:

This page: https://www.jmri.org/help/en/html/doc/Technical/index.shtml
includes the following text which links to sourceforge:


SourceForge.net provides project support:

Should this be replaced?

--SteveT


Re: Find some consensus

Pete Cressman
 



On Tuesday, July 21, 2020, 04:57:03 AM PDT, Randall Wood via groups.io <rhwood@...> wrote:

my response:
In my view Randall has misrepresented both examples for why he thinks there must be absolute veto power. But rather than argue the facts of these cases, I would like to point out that in both instances the submitter withdrew their proposal in lieu of the comments of the reviewers.

 I assume that all JMRI contributors respond to reasonable criticism and even acquiesce at times to preferences other than their own. Furthermore, I believe that they, like me, do a lot of manual testing well beyond what the test suite is capable of.  I do not believe anyone submits a PR with anything other than the best intensions. And in the event of a mistake, a misunderstanding of any kind can be reversed.

Other than Bob, I do not want anyone to have sole veto power. There is more i will leave unsaid.

Pete Cressman


Outdated Link to SourceForge?

Steve Todd
 

This page: https://www.jmri.org/help/en/html/doc/Technical/index.shtml
includes the following text which links to sourceforge:


SourceForge.net provides project support:

Should this be replaced?

--SteveT


Re: Find some consensus

Randall Wood <rhwood@...>
 


On 21-Jul-2020, at 01:55, Paul Bender <paul.bender@...> wrote:

All,

I want to come back to something Daniel said about peer review:
On Jul 19, 2020, at 7:18 PM, danielb987 <db123@...> wrote:
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.

This absolutely must not be implemented technically or as a policy. It must be possible to bar PRs for multiple reasons, be they legal, technical, or representing other risks.

JMRI does not exist in a vacuum, and incorporates materials under Trademark control (e.g. WiThrottle), that are maintained by third parties (aka dependencies) (e.g. OpenLCB), that may be dependended upon as API by third parties that cannot match the JMRI shipping schedule (e.g. the JMRI JSON protocols), or that are implementations of an externally defined protocol (e.g. the SRCP client and server). For any one of the above reasons, it must be possible to veto a PR that violates a Trademark or breaks an externally depended upon protocol.

See https://jmri-developers.groups.io/g/jmri/topic/29653009 for a very explicit reason why it must be possible to veto a PR — if the proposed no-veto policy was in place, and the original proposal had been submitted as a PR, we would have placed JMRI development into an untenable position of (at best) back-and-forth PRs or (at worst) lawsuits and externally dictated code freezes to deal with a legal problem) over a trademark violation.

Another recent example of a correctly vetoed PR was one where someone submitted a PR against OpenLCB, and then compiled his own JAR based on that PR and submitted it in a PR against a JMRI as an update to JMRI’s OpenLCB support. Meanwhile the PR against that dependency was rejected by the OpenLCB project (because it could not be reviewed because of the amount of whitespace changes). What would have happened if OpenLCB then published their own update that undid what JMRI now depended upon? Would have been forever stuck relying on some JMRI developer’s personal fork of OpenLCB? Would we have cease claiming to support OpenLCB until we no longer depended upon that personal fork (because the personal change broke something)?

This is not to say that there may have been incorrect vetos to changes, but that a blanket no-veto policy opens JMRI to not insignificant legal risks and risks to reputation (by risk to reputation, it would seriously hurt JMRI if the OpenLCB team decided that its better for them to fork JMRI to maintain a usable OpenLCB computer control software instead of relying on JMRI to be the reference OpenLCB computer control software).

The mechanics of this may not work, at least not using the built in tools.

GitHub lets you require one or more approving review before merging into protected branches, but if there is a review requesting changes, then the PR cannot be merged.

Perhaps there is a github integration/action we can use to apply custom rules to the process.

Now, that said, IF we are going to require reviews ( and I say If here because there are still at least two voices I would like to hear from ( Randall Wood and Dave Sand)) then we need to determine the rules of engagement so to speak.  In other words, what constitutes something that should have changes requested and what should just appear as a comment.

I think we should require reviews, knowing that project owners (right now Bob Jacobsen) and only project owners, can override/bypass those reviews when needed.

I also think that approving reviews should need to be re-approved if a code change happens after the approval (GitHub can enforce this).

As I said in another response on this thread, My rule of thumb is that you have to make it work first, then you can make it pretty.

What that means to me for code reviews:
1) Walk through the code and see if it should do what the developer writing it says it should.  If you can’t figure it out, ask questions.  Those questions could come in the form of a “changes requested” review,  but they could also be a comment.  If you use a “changes requested” review here, make sure to re-review once the explanation is made OR changes are made to make the code more readable.

2) If you are capable of testing the code with real hardware, download it and try it out. If it doesn’t work,  put up a changes requested review that includes how you made it fail.

As far as rules about the appropriateness of a change requested review, I’ll let this group decide that.

Randall


Re: Find some consensus

Paul Bender
 

All,

I want to come back to something Daniel said about peer review:
On Jul 19, 2020, at 7:18 PM, danielb987 <db123@...> wrote:
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.
The mechanics of this may not work, at least not using the built in tools.

GitHub lets you require one or more approving review before merging into protected branches, but if there is a review requesting changes, then the PR cannot be merged.

Perhaps there is a github integration/action we can use to apply custom rules to the process.

Now, that said, IF we are going to require reviews ( and I say If here because there are still at least two voices I would like to hear from ( Randall Wood and Dave Sand)) then we need to determine the rules of engagement so to speak. In other words, what constitutes something that should have changes requested and what should just appear as a comment.

As I said in another response on this thread, My rule of thumb is that you have to make it work first, then you can make it pretty.

What that means to me for code reviews:
1) Walk through the code and see if it should do what the developer writing it says it should. If you can’t figure it out, ask questions. Those questions could come in the form of a “changes requested” review, but they could also be a comment. If you use a “changes requested” review here, make sure to re-review once the explanation is made OR changes are made to make the code more readable.

2) If you are capable of testing the code with real hardware, download it and try it out. If it doesn’t work, put up a changes requested review that includes how you made it fail.

Paul


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.