Machinetalk - quo vadis?

[mlampert]

In my quest to figure out how machinetalk works I came across the following in mkwrapper.py:

def main():
    parser = argparse.ArgumentParser(
        description='Mkwrapper is wrapper around the linuxcnc python module'
        'as temporary workaround for Machinetalk based user interfaces'
    )

So if mkwrapper.py is/was considered a temporary workaround, how does/should the real thing look like?

[ce...@tuta.io]

27. 5. 2019 3:20 od mar...@bibi.ca:

Problem with Machinetalk, one which needs to be remembered at all times, is that it is in an unfinished state from a development point of view and probably the specification was never finished also. Hard to say as Michael Haberler, who cooked it up at the beginning, left the project and I don't know if Alexander Roessler is active in Machinetalk development anymore.

So short term band-aids become long term solutions. Not good but probably good enough for now.

As you can see the Machinetalk suffers a little bit by grandiose dreams which never materialized. Like the preparation work in Container message, https://github.com/machinekit/machinetalk-protobuf/blob/master/src/machinetalk/protobuf/message.proto#L128 <https://github.com/machinekit/machinetalk-protobuf/blob/master/src/machinetalk/protobuf/message.proto#L128> , for ZeroMQ thought up service discovery instead of DNS-SD/mDNS. Also, it didn't cover the problem of multiple transport protocols (IPC/TCP/UDP), which I think is sorely needed. And the NOTYET defines are still open work in the source code. From today point of view, I think it needs some rework. And I am open to discussion on how to do this. (I am of the opinion that the definition should be accessible before the code.)

Cern.
>
>
>
> --
> website: > http://www.machinekit.io <http://www.machinekit.io>> blog: > http://blog.machinekit.io <http://blog.machinekit.io>> github: > https://github.com/machinekit <https://github.com/machinekit>
> ---
> You received this message because you are subscribed to the Google Groups "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to > machinekit+...@googlegroups.com <mailto:machinekit+...@googlegroups.com>> .
> Visit this group at > https://groups.google.com/group/machinekit <https://groups.google.com/group/machinekit>> .
> To view this discussion on the web visit > https://groups.google.com/d/msgid/machinekit/6b0977ef-1595-4919-ae1b-faf3b8428670%40googlegroups.com <https://groups.google.com/d/msgid/machinekit/6b0977ef-1595-4919-ae1b-faf3b8428670%40googlegroups.com?utm_medium=email&utm_source=footer>> .
> For more options, visit > https://groups.google.com/d/optout <https://groups.google.com/d/optout>> .
>

[markus]

Thanks for the pointer, I had not looked at those fields in Container
yet - I can see that there were grand plans indeed, what I don't see
is where they were supposed to go.

And I mean that in many ways. It's not clear where each one of
these services was supposed to be implemented, how they were supposed
to be integrated with the rest (.ini file or some new mechanism) and
finally - I'm not entirely sure what problems some of them were
supposed to solve.

For instance status.config - if that had a fixed
(configurable in some way) port the service_announcement you
pointed to would make sense and be quite useful.

Can you elaborate what you meant by different transports? What is it
you are looking for?

Have fun,
Markus

[Bas de Bruijn]

Hi Cern and Markus,

Machinetalk has been the vehicle for having remote GUI’s. It’s been a solution so far, but that does not mean it’s complete. I can’t help you with that because that’s matter I do not have knowledge/experience on.

mkwrapper is a python wrapper around NML, https://github.com/machinekit/machinekit/pull/314

The Machinekit project once forked from LinuxCNC because some people were dissatisfied with the effort it took to have their code merged in the master branch.

That made that new features were slow to turn up into the master branch, if at all.

There is not “one grand designer” or “roadmap" that gives direction to this project. It’s up to people adding code that’s of their interest. And as some people add a lot of code it’s natural that these are to be the driving force behind a project. Taking it in a direction that scratches an itch or has their interest. So “direction” by “effect”.

I’m mostly interested in the HAL layer for example. I don’t have a lot of knowledge about the internals of the CNC stack, or on Haltalk for that matter. Although I do use them.

If you want to add/improve code and functionality on parts of the Machinekit project, that would be great and welcomed!

The difficulty arises in that these kinds of efforts are hard, so there will be only a few people who really understand what’s going on (that’s why it’s so difficult to understand the legacy code base).

Because of the C4 process, I as a maintainer do not have to know about code, or do “reviews” other than basic stuff. I do not decide if a PR is “good” or “bad” on the basis of what it does. The only thing I try to do (if that’s within my knowledge set) is to see if the PR does not break the API. We don’t want to mess up existing systems, especially because this kind of software is driving _real_ machines. If anybody uses Machinekit in a product and relies on a stable branch, it’s up for that person/company to fork and create a stable branch and take care of that. We have a build system that will show if packages are successfully built, and that’s my (literally) green light for merging. That simple. 

If for whatever reason a PR breaks the code, then either the maintainer being around fixes it, or if they are gone and nobody can fix it, we revert the PR.

If you want to add functionality, see problems, improve, the way this works (best) is:

• Create an issue on github for the repository it concerns.
• This is the focus point for the problem, and helps keeping the information/discussion centered
• Explain your case, discuss
• Have other people engaged in the discussion. This really helps.
• Hopefully this results you end up with likeminded people.
• Create PR’s preferably in small bits. Do not break the API.
• Smaller bits are easier and less “scarier” than a huge blob that only the author of the code understand. It creates progress, traction, increases the chance of early testing. Having said that, because the code can be difficult, PR's might be bigger if there are a lot of architectural changes needed. But either way, make a PR and it will be merged if it does not mess up the existing code. 

So long story short, Do not let the “there is no roadmap” fact hold you back.

Bas

--
website: > http://www.machinekit.io <http://www.machinekit.io>>
blog: > http://blog.machinekit.io <http://blog.machinekit.io>>
github: > https://github.com/machinekit
<https://github.com/machinekit> --- You received this message
because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to > machinekit+...@googlegroups.com
<mailto:machinekit+...@googlegroups.com>> . Visit this
group at > https://groups.google.com/group/machinekit
<https://groups.google.com/group/machinekit>> . To view this
discussion on the web visit >
https://groups.google.com/d/msgid/machinekit/6b0977ef-1595-4919-ae1b-faf3b8428670%40googlegroups.com
<https://groups.google.com/d/msgid/machinekit/6b0977ef-1595-4919-ae1b-faf3b8428670%40googlegroups.com?utm_medium=email&utm_source=footer>> .
For more options, visit > https://groups.google.com/d/optout
<https://groups.google.com/d/optout>> .

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit

---
You received this message because you are subscribed to the Google Groups "Machinekit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/20190527121558.02c13f85%40edeltraud.
For more options, visit https://groups.google.com/d/optout.

[ce...@tuta.io]

May 27, 2019, 9:15 PM by mar...@bibi.ca:

> Thanks for the pointer, I had not looked at those fields in Container
> yet - I can see that there were grand plans indeed, what I don't see
> is where they were supposed to go.
>

Have you looked at the videos at https://www.youtube.com/channel/UC3FVtrJ8U91iODq5motHMow <https://www.youtube.com/channel/UC3FVtrJ8U91iODq5motHMow> and read the wiki at https://github.com/mhaberler/asciidoc-sandbox/wiki <https://github.com/mhaberler/asciidoc-sandbox/wiki> ? There are some basic pointers. Otherwise, only the code and your imagination.

>
> And I mean that in many ways. It's not clear where each one of
> these services was supposed to be implemented, how they were supposed
> to be integrated with the rest (.ini file or some new mechanism) and
> finally - I'm not entirely sure what problems some of them were
> supposed to solve.
>
> For instance status.config - if that had a fixed
> (configurable in some way) port the service_announcement you
> pointed to would make sense and be quite useful.
>
> Can you elaborate what you meant by different transports? What is it
> you are looking for?
>

Well, ignore the overly dramatic parts of my monologue. When one says Machinekit (in extension from LinuxCNC), then even though many people will imagine Axis user interface and CNC mill connected by MESA card or parallel port, it is not by default one running program but set of arbitrary number more or less closely connected programs. Some of these program from definition and by logic need to run on the same system. Like the rtapi_msgd and rtapi_app which are connected by shared memory segment. Rtapi_app is then connected to some form of RT capable system. It can be the RT-Preempt patched linux kernel (pretty much standard libc), or the Xenomai Native API or whatever. Then there are programs which do not necessarily need to run on the same system, these program don't even need to run on Linux but could pretty well run on Windows too. Basically they can run anywhere from machine point of view. Cue for example the HALCMD command line tool or the AXIS GUI or even the trajectory planner and G-code interpreter.

So how I understand the Machinetalk idea it is global communication layer (application communication bus) for communication between Machinekit parts and more for communication with arbitrary outside programs (like work scheduling server). It should not care where the common parts of Machinekit are running (of course, parts which logically need to run on one system like the rtapi_msgd and rtapi_app are exception) if it is one i7 x86_64 computer or 10 small ARM based SBCs.

Also, currently you can have one or more rtapi_apps running on one system. These (lets call them) Machinekit instances can be pretty much independent. So you should be able to operate system which can be arbitrarily deployed on one or multiple platforms/machines (call them PC for short) and these platforms/machines/PCs can be part of multiple systems (Like node controlling environment can be part of 3D printer and CNC mill at the same time).

One example is the ATC to CNC mill. The ATC can (and maybe should) have it's own controller - Machinekit running it. This Machinekit controlling ATC will then communicate with Machinekit running the XYZSpindle milling motion.

So you need communication inside one machine and outside the machine over local network or arbitrary form. (We are still talking about non-deterministic communication, no synchronized motion or RT threads.) One service may need to communicate with remote actor and local actor at the same moment. The remote actors can be multiple and reachable by different network/interfaces. Also, not every network connection can be considered safe.

So far Machinekit implements Machinetalk which is either REMOTE or LOCAL. Remote means communication by TCP, local by IPC. But it's not that simple. You may want to communicate with local actors over IPC (with full rights, because who can get to the machine can do anything) and you may want to communicate with some remote actors by TCP with implemented CURVE and limited permissions on the same time on the same service. And then you want to communicate with another rtapi_app instance in the status/command mode. Locally you can use the IPC protocol, but remotely it is better to use the (multicasted) UDP over RADIO/DISH socket. (Little I described here: https://github.com/machinekit/machinekit-hal/issues/125 <https://github.com/machinekit/machinekit-hal/issues/125> ). Again same service can communicate on one time over UDP and IPC.

Hope it shone at least a little light onto what I mean.

Cern.

[ce...@tuta.io]

May 28, 2019, 7:36 AM by b...@basdebruijn.com:

> Hi Cern and Markus,
>
>
>> On 27 May 2019, at 21:15, markus <>> mar...@bibi.ca <mailto:mar...@bibi.ca>>> > wrote:
>>
>> Thanks for the pointer, I had not looked at those fields in Container
>> yet - I can see that there were grand plans indeed, what I don't see
>> is where they were supposed to go.
>>
>> And I mean that in many ways. It's not clear where each one of
>> these services was supposed to be implemented, how they were supposed
>> to be integrated with the rest (.ini file or some new mechanism) and
>> finally - I'm not entirely sure what problems some of them were
>> supposed to solve.
>>
>> For instance status.config - if that had a fixed
>> (configurable in some way) port the service_announcement you
>> pointed to would make sense and be quite useful.
>>
>> Can you elaborate what you meant by different transports? What is it
>> you are looking for?
>>
>> Have fun,
>> Markus
>>
>> On Mon, 27 May 2019 17:35:00 +0200 (CEST)

>> <>> ce...@tuta.io <mailto:ce...@tuta.io>>> > wrote:
>>
>>
>>> 27. 5. 2019 3:20 od >>> mar...@bibi.ca <mailto:mar...@bibi.ca>>>> :

> mkwrapper is a python wrapper around NML, > https://github.com/machinekit/machinekit/pull/314 <https://github.com/machinekit/machinekit/pull/314>
>
Yes, but it's not only that. I find it kind of a problem that when people talk about Machinetalk they mean remote GUI capability. It's like when people tell others that Machinekit is LinuxCNC for BeagleBone Black or BBB project.

Look for example at communication between rtapi_app instance and HALCMD application.

>
> The Machinekit project once forked from LinuxCNC because some people were dissatisfied with the effort it took to have their code merged in the master branch.
> That made that new features were slow to turn up into the master branch, if at all.
>

And I am glad for it. It is one of the reasons why I am here and not there.

>
> There is not “one grand designer” or “roadmap" that gives direction to this project. It’s up to people adding code that’s of their interest. And as some people add a lot of code it’s natural that these are to be the driving force behind a project. Taking it in a direction that scratches an itch or has their interest. So “direction” by “effect”.
> I’m mostly interested in the HAL layer for example. I don’t have a lot of knowledge about the internals of the CNC stack, or on Haltalk for that matter. Although I do use them.
>

I think that "roadmap" in some form is a good think. Or better yet RFC. Basically design of the project before code. Create general specification to which subsequent development should adhere. It is clearly missing in the form of Machinetalk (and it's subsets like HALtalk and so on) and given the fact that Machinetalk is basically decoupling API and lot of other programs depend on it in situations you cannot really determine, any change is minefield.

>
> If you want to add/improve code and functionality on parts of the Machinekit project, that would be great and welcomed!
> The difficulty arises in that these kinds of efforts are hard, so there will be only a few people who really understand what’s going on (that’s why it’s so difficult to understand the legacy code base).
>

Can concur, took me a long while to get to at least some proficiency.

> Because of the C4 process, I as a maintainer do not have to know about code, or do “reviews” other than basic stuff. I do not decide if a PR is “good” or “bad” on the basis of what it does. The only thing I try to do (if that’s within my knowledge set) is to see if the PR does not break the API. We don’t want to mess up existing systems, especially because this kind of software is driving _real_ machines.
>

Bingo. That's the core of the problem. Everybody assumes how the API is constructed or meant but nobody knows for sure. And for every change everybody will make there will be somewhere somebody who will be pissed off. Because his program of which you had no prior knowledge suddenly stops working. (Simplistic example can be seen here: https://github.com/machinekit/machinekit/pull/1456#discussion_r250955577 <https://github.com/machinekit/machinekit/pull/1456#discussion_r250955577> )

So any change must be of the big bang style.

> If anybody uses Machinekit in a product and relies on a stable branch, it’s up for that person/company to fork and create a stable branch and take care of that. We have a build system that will show if packages are successfully built, and that’s my (literally) green light for merging. That simple. 
> If for whatever reason a PR breaks the code, then either the maintainer being around fixes it, or if they are gone and nobody can fix it, we revert the PR.
>
> If you want to add functionality, see problems, improve, the way this works (best) is:
> Create an issue on github for the repository it concerns.
>

When I will have everything completely summarized, will do.

> This is the focus point for the problem, and helps keeping the information/discussion centered
> Explain your case, discuss
> Have other people engaged in the discussion. This really helps.
> Hopefully this results you end up with likeminded people.
> Create PR’s preferably in small bits. Do not break the API.
>

In many cases it is not possible to not break API. What is possible is to create second version which will live alongside the original implementation. And like the mkwrapper that's probably OK too.

Cern.

> Smaller bits are easier and less “scarier” than a huge blob that only the author of the code understand. It creates progress, traction, increases the chance of early testing. Having said that, because the code can be difficult, PR's might be bigger if there are a lot of architectural changes needed. But either way, make a PR and it will be merged if it does not mess up the existing code. 
> So long story short, Do not let the “there is no roadmap” fact hold you back.
>
> Bas
>
>
>>>>
>>>>
>>>>
>>>> --

>>>> website: > >>>> http://www.machinekit.io <http://www.machinekit.io>>>>> <>>>> http://www.machinekit.io <http://www.machinekit.io>>>>> >>
>>>> blog: > >>>> http://blog.machinekit.io <http://blog.machinekit.io>>>>> <>>>> http://blog.machinekit.io <http://blog.machinekit.io>>>>> >>

>>>> github: > >>>> https://github.com/machinekit <https://github.com/machinekit>
>>>> <>>>> https://github.com/machinekit <https://github.com/machinekit>>>>> > --- You received this message
>>>> because you are subscribed to the Google Groups "Machinekit" group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>>>> send an email to > >>>> machinekit+...@googlegroups.com <mailto:machinekit+...@googlegroups.com>

>>>> <>>>> mailto:machinekit+...@googlegroups.com <mailto:machinekit+...@googlegroups.com>>>>> >> . Visit this

>>>> group at > >>>> https://groups.google.com/group/machinekit <https://groups.google.com/group/machinekit>
>>>> <>>>> https://groups.google.com/group/machinekit <https://groups.google.com/group/machinekit>>>>> >> . To view this
>>>> discussion on the web visit >

>>>> https://groups.google.com/d/msgid/machinekit/6b0977ef-1595-4919-ae1b-faf3b8428670%40googlegroups.com <https://groups.google.com/d/msgid/machinekit/6b0977ef-1595-4919-ae1b-faf3b8428670%40googlegroups.com>

>>>> <https://groups.google.com/d/msgid/machinekit/6b0977ef-1595-4919-ae1b-faf3b8428670%40googlegroups.com?utm_medium=email&utm_source=footer>> .
>>>> For more options, visit > https://groups.google.com/d/optout
>>>> <https://groups.google.com/d/optout>> .
>>>>
>>>
>>>
>>
>> --
>> website: >> http://www.machinekit.io <http://www.machinekit.io>>> blog: >> http://blog.machinekit.io <http://blog.machinekit.io>>> github: >> https://github.com/machinekit <https://github.com/machinekit>
>> ---
>> You received this message because you are subscribed to the Google Groups "Machinekit" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to >> machinekit+...@googlegroups.com <mailto:machinekit+...@googlegroups.com>>> .
>> Visit this group at >> https://groups.google.com/group/machinekit <https://groups.google.com/group/machinekit>>> .

>> To view this discussion on the web visit >> https://groups.google.com/d/msgid/machinekit/20190527121558.02c13f85%40edeltraud <https://groups.google.com/d/msgid/machinekit/20190527121558.02c13f85%40edeltraud>>> .

[Bas de Bruijn]

Indeed.

>
> Look for example at communication between rtapi_app instance and HALCMD application.
>
>>
>> The Machinekit project once forked from LinuxCNC because some people were dissatisfied with the effort it took to have their code merged in the master branch.
>> That made that new features were slow to turn up into the master branch, if at all.
>>
> And I am glad for it. It is one of the reasons why I am here and not there.
>
>>
>> There is not “one grand designer” or “roadmap" that gives direction to this project. It’s up to people adding code that’s of their interest. And as some people add a lot of code it’s natural that these are to be the driving force behind a project. Taking it in a direction that scratches an itch or has their interest. So “direction” by “effect”.
>> I’m mostly interested in the HAL layer for example. I don’t have a lot of knowledge about the internals of the CNC stack, or on Haltalk for that matter. Although I do use them.
>>
> I think that "roadmap" in some form is a good think. Or better yet RFC. Basically design of the project before code. Create general specification to which subsequent development should adhere. It is clearly missing in the form of Machinetalk (and it's subsets like HALtalk and so on) and given the fact that Machinetalk is basically decoupling API and lot of other programs depend on it in situations you cannot really determine, any change is minefield.

I’ve done automation projects as you describe. Design behaviour before code. State machine, sequence diagrams etc.

We can create a designated page/section in the docs? We’re using Jekyll and asciidoc to create the website and documentation. Using plantuml graphics in those asciidocs is a no brainer. And a picture says more than... you know...

>
>>
>> If you want to add/improve code and functionality on parts of the Machinekit project, that would be great and welcomed!
>> The difficulty arises in that these kinds of efforts are hard, so there will be only a few people who really understand what’s going on (that’s why it’s so difficult to understand the legacy code base).
>>
> Can concur, took me a long while to get to at least some proficiency.
>
>> Because of the C4 process, I as a maintainer do not have to know about code, or do “reviews” other than basic stuff. I do not decide if a PR is “good” or “bad” on the basis of what it does. The only thing I try to do (if that’s within my knowledge set) is to see if the PR does not break the API. We don’t want to mess up existing systems, especially because this kind of software is driving _real_ machines.
>>
> Bingo. That's the core of the problem. Everybody assumes how the API is constructed or meant but nobody knows for sure. And for every change everybody will make there will be somewhere somebody who will be pissed off. Because his program of which you had no prior knowledge suddenly stops working. (Simplistic example can be seen here: https://github.com/machinekit/machinekit/pull/1456#discussion_r250955577 <https://github.com/machinekit/machinekit/pull/1456#discussion_r250955577> )
>
> So any change must be of the big bang style.
>
>
>> If anybody uses Machinekit in a product and relies on a stable branch, it’s up for that person/company to fork and create a stable branch and take care of that. We have a build system that will show if packages are successfully built, and that’s my (literally) green light for merging. That simple.
>> If for whatever reason a PR breaks the code, then either the maintainer being around fixes it, or if they are gone and nobody can fix it, we revert the PR.
>>
>> If you want to add functionality, see problems, improve, the way this works (best) is:
>> Create an issue on github for the repository it concerns.
>>
> When I will have everything completely summarized, will do.
>
>> This is the focus point for the problem, and helps keeping the information/discussion centered
>> Explain your case, discuss
>> Have other people engaged in the discussion. This really helps.
>> Hopefully this results you end up with likeminded people.
>> Create PR’s preferably in small bits. Do not break the API.
>>
> In many cases it is not possible to not break API. What is possible is to create second version which will live alongside the original implementation. And like the mkwrapper that's probably OK too.

Yes, that’s the way, create a second version. That’s what’s been done previously.

[ce...@tuta.io]

May 29, 2019, 12:33 PM by b...@basdebruijn.com:

>
>
>> On 28 May 2019, at 23:59, <ce...@tuta.io> <ce...@tuta.io> wrote:
>>

> Indeed.

>
>>
>> Look for example at communication between rtapi_app instance and HALCMD application.
>>
>>>
>>> The Machinekit project once forked from LinuxCNC because some people were dissatisfied with the effort it took to have their code merged in the master branch.
>>> That made that new features were slow to turn up into the master branch, if at all.
>>>
>> And I am glad for it. It is one of the reasons why I am here and not there.
>>
>>>
>>> There is not “one grand designer” or “roadmap" that gives direction to this project. It’s up to people adding code that’s of their interest. And as some people add a lot of code it’s natural that these are to be the driving force behind a project. Taking it in a direction that scratches an itch or has their interest. So “direction” by “effect”.
>>> I’m mostly interested in the HAL layer for example. I don’t have a lot of knowledge about the internals of the CNC stack, or on Haltalk for that matter. Although I do use them.
>>>
>> I think that "roadmap" in some form is a good think. Or better yet RFC. Basically design of the project before code. Create general specification to which subsequent development should adhere. It is clearly missing in the form of Machinetalk (and it's subsets like HALtalk and so on) and given the fact that Machinetalk is basically decoupling API and lot of other programs depend on it in situations you cannot really determine, any change is minefield.
>>
>

> I’ve done automation projects as you describe. Design behaviour before code. State machine, sequence diagrams etc.
>
> We can create a designated page/section in the docs? We’re using Jekyll and asciidoc to create the website and documentation. Using plantuml graphics in those asciidocs is a no brainer. And a picture says more than... you know...
>

Sure, special section in the docs could be helpful. I have been thinking about somehow integrating all these informations from MH's wiki and videos and AR's blog serial into the docs as the current situation when every soul interested in Machinetalk is send to some obscure sources as a first thing is not very good. And even though there is some "documentation" about Machinetalk Protobuf messages, it is auto-generated and my first reaction when I have seen it was "WTF is this mess?" So it becomes useful one gets the idea what Machinetalk is about.

However, the questing remains who will write it and who will comment on it? I can write some, but some kind of collaboration would go a long way.

Cern.

>>>
>>> If you want to add/improve code and functionality on parts of the Machinekit project, that would be great and welcomed!
>>> The difficulty arises in that these kinds of efforts are hard, so there will be only a few people who really understand what’s going on (that’s why it’s so difficult to understand the legacy code base).
>>>
>> Can concur, took me a long while to get to at least some proficiency.
>>
>>> Because of the C4 process, I as a maintainer do not have to know about code, or do “reviews” other than basic stuff. I do not decide if a PR is “good” or “bad” on the basis of what it does. The only thing I try to do (if that’s within my knowledge set) is to see if the PR does not break the API. We don’t want to mess up existing systems, especially because this kind of software is driving _real_ machines.
>>>
>> Bingo. That's the core of the problem. Everybody assumes how the API is constructed or meant but nobody knows for sure. And for every change everybody will make there will be somewhere somebody who will be pissed off. Because his program of which you had no prior knowledge suddenly stops working. (Simplistic example can be seen here: https://github.com/machinekit/machinekit/pull/1456#discussion_r250955577 <https://github.com/machinekit/machinekit/pull/1456#discussion_r250955577> )
>>
>> So any change must be of the big bang style.
>>
>>
>>> If anybody uses Machinekit in a product and relies on a stable branch, it’s up for that person/company to fork and create a stable branch and take care of that. We have a build system that will show if packages are successfully built, and that’s my (literally) green light for merging. That simple.
>>> If for whatever reason a PR breaks the code, then either the maintainer being around fixes it, or if they are gone and nobody can fix it, we revert the PR.
>>>
>>> If you want to add functionality, see problems, improve, the way this works (best) is:
>>> Create an issue on github for the repository it concerns.
>>>
>> When I will have everything completely summarized, will do.
>>
>>> This is the focus point for the problem, and helps keeping the information/discussion centered
>>> Explain your case, discuss
>>> Have other people engaged in the discussion. This really helps.
>>> Hopefully this results you end up with likeminded people.
>>> Create PR’s preferably in small bits. Do not break the API.
>>>
>> In many cases it is not possible to not break API. What is possible is to create second version which will live alongside the original implementation. And like the mkwrapper that's probably OK too.
>>
>

> Yes, that’s the way, create a second version. That’s what’s been done previously.
>
>>

> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit

> ---
> You received this message because you are subscribed to the Google Groups "Machinekit" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/BE82C931-051D-4474-9409-266BF4F05A9B%40basdebruijn.com.
> For more options, visit https://groups.google.com/d/optout.
>