In a project that has defined leadership, full time coders, established practices, and a well organized, slowly evolving, historical codebase to protect, I would fully agree. Here, we are not encumbered by all of that. You are probably right about pull requests, but I disagree about forks. Perhaps there is middle ground. https://www.slant.co/topics/7247/~code-snippets-manager ?
We have rapid development in many different directions. Yes, that indicates forks. But I encourage “Official Forks” for each proposed platform. Otherwise known as branches, or perhaps even alternative projects under the Maslow umbrella.
Forks do not appear under the umbrella of the main organization. People that can contribute only snippets are reluctant to work on other peoples’ forks because there is no clear way to get their contributions merged upstream. Yeah, you are an upstream now. They are reluctant to create their own fork because they only ever plan to contribute one or 2 snippets and aren’t interested in maintenance. We need to capture those snippets somehow. I may not have the answer, but …
** We need an easy way for Joe Blow to quickly write some bad code with promising ideas. Even pseudo code that won’t compile. Quickly get it in front of some central eyeballs for evaluation, refinement, adoption; of which the original coder was incapable. **
Great coders may be completely lost using Github because they retired before it was a thing and refuse to learn, but they still know C.
We have very few people that understand most of the code (I do not understand most of the code), and a lot of people that understand little bits that could contribute snippets. I think it is unreasonable to expect every developer to fully understand the global impact on hardware and software when they just want to show you 20 lines of Arduino code.
That’s what issues are for in a github repository. open an issue to discuss an idea or a problem, and to field suggestions before making changes to the code base. Issues can be discussed as long as need be, PRs have a much shorter time before being merged.
Yes, issues is better for discussing specific code than the forum, agreed. But if the issue is ever to be resolved, it needs to end in a pull request. I assume we are not going the route of assigning issues? That leaves the PR up to the original developer, or someone ‘take charge’ enough to submit it on his behalf. So we are back to the original problem how do we know when the PR is ready? Especially if the coder cant tell if it is ready himself.
In theory, theory and practice are the same, in practice they are different.
In theory you are right, but in practice, there’s no clean line between code
that isn’t perfect and code that is production-ready
anything submitted as a PR should be expected to not cause any harm, but it may
add an optional feature that the contributer thinks is ready and a step forward,
but needs to be tested by a lot of people (holey calibration being a perfect
example)
If we had paid programmers, you can try to hold them to the “prove it’s good”
standard, but with community projects, it’s much better to have a “it shouldn’t
hurt anyone” standard instead and iterate through changes and improvements.
we do need a way to tell the merge robot “this needs more attention, don’t close
it or merge it, put it on hold for a while”
Does this firmware change affect kinematics or any part of the calibration process?
I understand the need to know the answer, but find it difficult or impossible to answer No conclusively for almost any substantive change in firmware. Could anyone offer a test that demonstrates no affect on kinematics or calibration?
if it doesn’t change the kinematics calculations code, it’s very unlikely that
the answer is yes. But this is why I would like to see the robot flag changes to
the particular source file rather than relying on asking the question.
So as a guide, which files are the ‘dangerous’ ones? For example, I see that the encoder library has upstream version bumps. How would we test the 1.4.1 version to see if it affects calibration or kinematics?
I’ve tested that version of the Encoder library, there are some changes needed to make it work with the Maslow firmware. In particular, the values elapsedTime and lastTime which the Maslow relies on were dropped a few versions ago. Not too hard to weave those back in, though. One test could be to run a pattern cut before and after changing just the Encoder library and verify identical operation.
One plus to that version is that it brings compatibility with a flock more processors.
If we make it the sole responsibility of the software developer to do the testing, and the testing requires cutting, then we have severely limited the pool of software developers to those that own a functioning Maslow and are willing to make sawdust for free. Is there any way a software person without Maslow hardware can still contribute? They can run simulation, but is that alone acceptable?
I’m wondering if there could be 1 designated testing rig somewhere with a webcam pointed at it and a regularly scheduled operator running tests. That would go a long way toward uniform test procedures. I’m thinking some company with interns or a university with work study students, or a maker space that provides the labor in exchange for a free machine.
This came up with the ESP32 grbl port also. It makes sense for us to eventually try to get our required changes merged back into the projects we borrow code from so we remain in sync and compatible. I think it makes sense to only approach them after a release has been proven for a bit. Someone needs to make the contact on behalf of the Maslow project. Do we require a procedure to establish bonafides for a member representing the project? How does that work?
So as a guide, which files are the ‘dangerous’ ones?
really it’s kinematics.cpp and kinematics.h that are the most dangerous, changes
to them are likely to result is subtle changes that surprise people. Most other
changes will either work or not work
How would we test the 1.4.1 version to see if it affects calibration or
kinematics?
it is extremely unlikely to affect either. It can fail (including failing under
some odd conditions that are hard to predict) and cause errors to accumulate,
but it’s not going to change the movemetn calculations or calibration.
I already posted there to talk about our kinematics. I don’t think it needs to
be an ‘official representative of the maslow project’, just someone ho can talk
about what we are doing and the code to submit the patches and work through any
changes they ask for (which can be submitting back to the maslow project)
If we make it the sole responsibility of the software developer to do the
testing, and the testing requires cutting, then we have severely limited the
pool of software developers to those that own a functioning Maslow and are
willing to make sawdust for free.
I’ll also say that testing by the submitter isn’t enough. Going back all the way
to Bar’s original machine, he had it working well, but nobody else was able to
duplicate his results with the kickstarter kits, which is what drive us to
figuring out calibration and the weaknesses in the machine.
Is there any way a software person without Maslow hardware can still
contribute? They can run simulation, but is that alone acceptable?
in part it’s going to depend on what they are changing, there are a lot of
changes that can be made and reviewed by others without any hardware or cutting
involved (introducing support for new g-codes like the G54 command for example)
other changes like the encoder library require real hardware testing, but not a
fully working maslow. to test the encoders, you would want to make the motors
turn a lot (possibly back and forth with changes in direction and speed) and
make sure that the sprockets end up as expected (when we were testing the
gearbox ratio, we set the motors to turn 50 revolutions to see if the same tooth
ended up at 12 o-clock or not so that even minor errors would have a chance to
multiply to be human visable)
I’m wondering if there could be 1 designated testing rig
somewhere with a webcam pointed at it and a regularly scheduled operator
running tests. That would go a long way toward uniform test procedures.
we wouldn’t want to do one cutting that’s unattended, but we could set something
up with a pen setup.
I have one that I could probably rig up with webcontrol (with assitance) to run
regularly with a pen.
If that were on the main page, I bet it would drive interest in the project. One day per week, let unique visitors on the site have 30 seconds of machine time, or something like that. That got me thinking of adding a 4th axis for a paper roll to clear the plotter area. That shouldn’t be hard to work in. I’m not trying to volunteer you, just thinking out loud.
Thus the need for auto paper roll and 30 second limit on machine time. They can draw whatever they want, but it only lasts 30 seconds. What better viral publicity than an excited teen drawing dirty pictures and sharing the link around school? Including shop and art class. Its not like the internet police are gonna get us.
After a whole roll is written, auction it off as “Community Art”. Maslow could draw a timestamp on each frame, and we have a record of the evolution of collaborative art. It will probably start as all D__ks and B__bs but if we are lucky, it could evolve into something better. Or not. Its still an interesting experiment and the closest thing to a live demo until we can walk into a store and put our hands on one. But, not about release process. Sorry for the digression.
30 seconds isn’t enough to do anything useful. I’m thinking more along the lines
of drawing test patterns with different codebases (new patterns can be added,
but we need to check them first.
It’s too easy to damage these machines with malicious g-code (think how easy it
is to destroy the Z axis orange nut for example)
open an issue to discuss an idea or a problem, and to field suggestions before making changes to the code base. Issues can be discussed as long as need be, PRs have a much shorter time before being merged.