Right, I would like to see the firmware and Ground Control be very stable while we focus development effort on a GRBL port
I like stable, but I assume that doesn’t mean frozen… I think holey calibration and the catenary equations are useful additions… just think we ought to allow for a smooth transition for people to use them.
No, not frozen at all. Just that it’s OK if a release takes a week longer to get out to let more people test it
I agree we want to figure out how to get these in.
we want to figure out the kinematics and calibration without also fighting the
grbl port effort at the same time. Once we have the kinematics figured out, and
the port figured out, we can then update the kinematics in the grbl port.
I don’t think we can delay starting the voting process based on the description
in the PR
we may be able to delay the start based on changes to a particular file.
I wasn’t suggesting the questions be interactive in the group. Only that there are likely a short list of questions as @madgrizzle started to outline that end users should ask themselves in order to be able to provide good feedback to try and get towards root cause.
This is a real concern that is unique compared to pure software projects when regressions and updates can often be tested with just human time or automation. Materials and cutting and supervision have a higher friction on top of basic SW testing.
Perhaps the kit resellers could through $5 a sale or something in to a fund for testers for materials? Sheet costs add up fast in addition to time and lost opportunity of projects not completing.
Are there any standard validation cut patterns like the zipper tree or others that are done for a given release?
Moving to a docker container inside a Pi image or dedicated VM images per release version would allow users to relatively easily boot back in to the old version and continue a project if the new version proves problematic. Would likely take some work on the firmware update front to downgrade and ensure they stay in sync but it would hopefully reduce testing risk and friction. I always was to know my reversion plan before I start an upgrade. Too many years in telecom.
For webcontrol, the current (as of the time of release) stock firmware, optical calibration firmware, and holey calibration firmware are compiled and embedded in the docker. It would be a matter of just pushing a button to load the firmware… no need to load arduino ide, etc.
That is awesome news. I may be the odd man out but I don’t know that that information is widely known. Maybe if we summarize and promote those kinds of details on a how to and make it sticky or something without requieijg mavigating a 400 post thread we can lure in some new testers who were on the fence about touching s working setup.
I am happily struck by the answer almost slays being available in the community or offered when asked but also by how there is an opportunity to consolidate the info and make it easier for self service too. It’s a difficult challenge in a fast moving and dynamic project for sure.
I’m going to delete the 1.27 release until we are confident that it is stable enough for people to use. I’ve been hearing about more people having trouble with it, and I figure for everyone we hear about there are a couple people who don’t make it to the forums
There’s been a lot of PR’s integrated into V1.27 and some make some under-the-hood changes that aren’t as visible as the kinematics change. I worry about how well those PR’s have been tested and proven as well.
I’ve tested the PR#526 Firmware in FAKE_SERVO mode, and in real mode with motors but no sled, but not with chips flying. That real-world testing that is important, but I don’t have the frame set up to do it here.
I think both of these should be addressed by the process. Do our best to limit it to a few concise questions with obvious value in the answers. Not require that the initial contributor supply all the answers, but allow the community to contribute testing experiences and fill in the questions. That presents a lower hurdle for a developer to submit code that may not be perfect, but expose it to the community where it may be improved. PR doesn’t graduate from development branch to release candidate without all the testing questions answered by someone. It could be presented as a poll.
Does this PR do X?
Does this PR do Y?
Does this PR do Z?
It isn’t merged until there is at least 1 positive response to each question.
I think forks are the appropriate place for code that may not be perfect. Invite others to use the code and help improve it.
I think the purpose of a PR is to submit production-ready changes. The contributor should take the time to thoroughly vet the code being submitted, and document ways to demonstrate the issue that a change addresses and how to prove that it fixes it.
You and I are guilty of many of those changes - should we write up summaries like the one you put in PR#528?
Well, I really didn’t have many changes over last 8 months… I think mostly the eeprom work and changing of default settings… but would be happy to go back and comment on the ones I did.
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.