Closed davidelang closed 5 years ago
New releases need to encompass tested changes. Has everyone taken the time to run the master branch and confirm that it's "ready for prime time"? I run my patches against various motor control boards with a static motor lash up, but that's not the same thing.
well, at one point we were making frequent releases so that each release had a smallish number of changes
Since January, we have most of holey triangulation merged here so the set of changes is rather drastic.
If you wait until all the changes are tested extensively after merging, you never make a release. If you have frequent releases, the bugs that get through aren't that bad as you can just revert to the prior release. waiting 6 months breaks this deal, so we probably do need explicit testing of the release.
David Lang
I agree with @blurfl here. I took a little while to think about it, but I think unless we see some big changes made I don't want to bump things too much without the ability to test them. I am working on a version of the firmware for a 4 motor machine targeted to the esp32, but it will be a separate repository since it's basically a ground up re-write. Unless there is a very compelling reason to mess with the existing firmware I don't want to take the chance of releasing something bad for negligible improvement
I'm preparing a PR to add a new board based on the TLE9201. It touches System, Motor, and cnc_ctrl_v1.ino . I've tested it against the stock Maslow boards and the TLE5206 version in the Community Garden. Should I wait until after the next release to open the PR?
since we don't have any idea when that release will be, I wouldn't wait.
David Lang
Absolutely make the pull request. I think my new firmware is going to involve so many changes (adding wifi, four motors...etc) that it will be a separate repository.
If you have a new board to add then by all means make a pull request here!
It looks to me like releasing Firmware v1.27 at this point would capture:
Merged #480 Change originalChainLength to 1651 mm Merged #481 Chain length calculation improvement: stretch compensation Merged #486 Step further back to PlatformIO 3.5.3 Merged #489 Fix to EEPROM write issue Merged #490 change firmware link Merged #494 detach() should run once per state change Merged #498 Move directWrite outside the loop Merged #499 Avoid compiler warnings about aux3...aux9 Merged #501 Avoid PWM value 255 for TLE5206 Merged #507 rename RingBuffer to maslowRingBuffer Merged #510 When (pinCheck >= 6) the board version matches the version strapping Merged #512 Alarm if board version is unrecognized Merged #513 recognize a soft reset command in the serial stream Merged #514 Limit PWM frequency value
I think you are right that doing a release is the right thing to do. I think I'm just nervous because I don't have the right hardware setup to test everything.
what is the testing procedure that you want to do? Document it so that others can do it (either because your machine is down or because you are busy on other things)
David Lang
don't have the right hardware setup to test everything.
I'm in much the same boat. I think the release would change the EEPROM layout because of the added chain stretch values - doesn't that trigger a recalibration?
I certainly have the time, the trouble is that I am working out of a hacker space in Kyiv and I don't have the hardware with me. I only have new hardware for the next version which is in progress.
I never had an exact procedure, I would try to live with the new firmware for a few days and make at least one cut. I think if we could get two people who feel comfortable to test it and report back, that would be enough to make me feel comfortable.
On Wed, Jul 24, 2019, 9:44 PM Scott Smith notifications@github.com wrote:
don't have the right hardware setup to test everything.
I'm in much the same boat. I think the release would change the EEPROM layout because of the added chain stretch values - doesn't that trigger a recalibration?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MaslowCNC/Firmware/issues/515?email_source=notifications&email_token=ACHNAV36D45OIVKGXZQ4RZLQBCPKPA5CNFSM4IEIUDH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2XICVA#issuecomment-514752852, or mute the thread https://github.com/notifications/unsubscribe-auth/ACHNAV5VA6GZFWOVCDUXVIDQBCPKPANCNFSM4IEIUDHQ .
what is the testing procedure that you want to do?
Same question here, was about to take a 3rd run on holey calibration, but can shift priorities. The current master of FW/GC? What needs to be tested. Have the next 2 days available. Kind regards, Gero
Thanks @gero! The main concern is avoiding something being catastrophically wrong, like the serial connection isn't stable or gcode doesn't run properly. If the process of updating and running a cut goes smoothly, I think that would be a good start.
On Thu, Jul 25, 2019, 12:42 PM Gero notifications@github.com wrote:
what is the testing procedure that you want to do?
Same question here, was about to take a 3rd run on holey calibration, but can shift priorities. The current master of FW/GC? What needs to be tested. Have the next 2 days available. Kind regards, Gero
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MaslowCNC/Firmware/issues/515?email_source=notifications&email_token=ACHNAV744JJBXHPZ4AFUXMDQBFYQHA5CNFSM4IEIUDH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2Y6NNQ#issuecomment-514975414, or mute the thread https://github.com/notifications/unsubscribe-auth/ACHNAV622JQZW3PJN3FXQV3QBFYQHANCNFSM4IEIUDHQ .
Extensive fake server runs tonight. Dry runs with TLE5206 tomorrow after first coffee.
Thanks @GeroBH ! Here are some things to check that stand out to me:
I saw this to late and the second of my '2 days off' was stolen by work as usual. So only making Fake-Server crash at around 11538 lines of g-code was achieved. That's not to do with 1.27 release i think. Carried over a few releases is more likely.
The good news is that i can't make the Arduino 'insane' any more. (Ref: https://forums.maslowcnc.com/t/2-bugs-or-not-2-bugs-that-is-the-question-arduino-insane/9105) Something very positive might have happened to EEPROM write.
That is fantastic, and gives me a lot of confidence. It feels good to know that not only have we not seen something catastrophically wrong, but we have seen an old issue fixed by general best practices. Nice work.
Where does this leave us? Are we ready to do the update?
something to think about, with us talking about merging holey calibration and potentially switching to recommending WebControl vs GroundControl going forward, I think we are talking about changes significant enough to consider making that version 2.0
Ok, I've got my build environment working again and I have a plan.
I've been thinking about who should be responsible for testing releases and I think that the people selling kits should have to sign off on if a version is ready to release or not before we send it out. They are the ones who will be getting emails from grumpy customers if something is off.
It's getting late here, but in the morning when I can write a coherent email, I am going to write an email with attached version of the software to them to test. When they give the goahead I will make the release.
@blurfl If I update the buld-OSX branch are you able and willing to run an OS X build?
@blurfl If I update the buld-OSX branch are you able and willing to run an OS X build?
Sure thing!
Release updated!
no releases have happened since January
We need to document (if not automate) the release process and make it so multiple people can make the release.
see the similar issue on the firmware https://github.com/MaslowCNC/GroundControl/issues/795