Like I said, I wasn’t trying to build a monster. The suggestion could be limited to just kinematic related items that affect the performance of the machine… this is my main concern after recent events. If they answer no to the first question, no need going on. But if someone is proposing a change to kinematics, these are questions that I would want to know answers to before giving a thumbs up. And I’d rather there not be the start of the voting process until these questions are answered.
1 Like
I fully support this idea. GitHub actually allows us to create a template which shows up whenever a pull request is made making it really easy to check the boxes. I will create a pull request to add a template like that and solicit feedback on how it should be worded.
I agree that is a valid concern, but I also don’t want to scare off users of the machine by providing them with software which doesn’t work
2 Likes
There’s that as well as existing users wasting time and expensive material because the machine isn’t cutting the way it was before the update.
1 Like
Right, I would like to see the firmware and Ground Control be very stable while we focus development effort on a GRBL port
1 Like
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.
2 Likes
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
2 Likes
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.
David Lang
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.
David Lang
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.
Jeff
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?
Jeff
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.
Jeff
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.
1 Like
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.
Jeff
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
2 Likes
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.
2 Likes
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.
1 Like
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.
1 Like
You and I are guilty of many of those changes - should we write up summaries like the one you put in PR#528?
1 Like
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.