Developer Meeting Agenda 2026-09-27 - 20:00 CEST #4566
Replies: 3 comments 7 replies
|
Short comment on 8. hm2_eth read timeouts on real hardware, issue #4525 dd68759 does not drop any more or less packages than before, at least not intentionally. It only changes the timeouts from polling A noticeable difference I introduced is a message that shows receive timeouts, so it makes timeouts visible. All other logic already existed and was not changed. Reducing the CPU load or using But it could also simply be that making the timeouts visible gave a false positive while bisecting. If desired, I can join the meeting. |
|
You are welcome to join, not sure who else is going to be present, it's too late for me... @BsAtHome is most probably going to be there, worst case scenario you can have a nice chat with him ;-) |
If you can, please do. It is often easier to talk about a problem than to read about it. |
|
With regard to #3, I apologize, as I won’t be able to attend the meeting. I know I wasn’t asked to attend - I found out about it through the developer email chain on the SourceForge website - but I wanted to at least have some representation, particularly since it appears that others may be coming into the discussion with an established agenda. What most concerns me is not that Chris made a perceived mistake (he did have plenty of discussion surrounding the changes from what I saw). Mistakes happen, and I have no objection to discussing how changes to the project should be reviewed going forward. What concerns me is the way a long-time contributor to this project has been treated as a result. There are not many active developers left on this project, and there are even fewer who have been around long enough to understand the history and context behind the code. That institutional knowledge has value, and I don't think it should be dismissed. For some examples, look at the discussion surrounding commits 7ebe7d9, 9d79c2a, 9a45ed9, and 13b52cb. The point isn't to dredge up the past, it is to point out that the standard now apparently being applied to Chris’ commits only seems to apply since someone didn’t like having their toes stepped on. I am certainly not opposed to code review. I have opened plenty of PRs for changes where I wanted another set of eyes. I also have commits where I discussed the changes with other developers privately before committing them. I have no problem with review when it is actually useful and appropriate. Collaboration definitely moves things forward. What I do object to is changing the rules without discussion and then treating someone as though they violated an established process when that process did not previously exist or was not previously enforced. There is also a long-standing precedent for having a maintainer responsible for a particular portion of the project. As long as I have been contributing, GUIs have effectively operated that way. The users generally do not care whether a particular GUI feature was implemented through a PR, a direct commit, or some other mechanism. They cared that the feature worked and that bugs were fixed. If the project now wants to move to a different development model, I am willing to discuss that. But I don't think it is reasonable to silently change the process, apply it retroactively, selectively, and then use someone's mistake as justification for the change. |
|
Agree with the sentiment here, the discussion is still ongoing in the mailing list as well. https://sourceforge.net/p/emc/mailman/emc-developers/ Reading @rene-dev messages, he made the change on the basis that it was implicitly already agreed by all devs, that assumption turned out to be wrong, my stance FWIW is that the restriction should be rolled back, and the discussion moved forward, possibly on the mailing list or on #4558 a discussion I opened for that purpose, or in a live meeting which could be organized at other times to fit the schedules of the effected devs... The most visible portion of the discussion seems to be on the mailing list, I'd suggest you also post this there for more visibility. |
You are always welcome. |
|
@grandixximo thank you for the reply, nice to know we are on the same page! I don’t get the dev emails, I’m not sure how to respond other than emailing the list which would start a new thread. Is it possible for you to reply on my behalf and just copy a link to direct them to my message above? I read the chain and I agree with Chris’ sentiments that it’s ok when others break our GUIs, but the moment a mistake is made from the other direction a unilateral nuclear option is chosen. It very much feels like “rules for thee and not for me”. I’ve always felt like fixing the things that got broken and affected the stuff I am very familiar with was just sort of “part of it”. There’s a lot of moving pieces to this project. But lately it definitely feels like there’s an unspoken agenda, for what I’m not quite sure but it’s not a good look. @BsAtHome thank you for the standing invite. Do these get recorded so others can listen in after the fact? I would be interested in that as I have a one hour commute both ways for my day job and I could treat it like a podcast of sorts. Otherwise my wife’s work schedule and my toddler make it difficult for me to attend meetings outside of my day job (which sounds like an excuse but is how it is right now…). |
I certainly hope not. If they are recorded, then I'd withdraw my participation. |
|
@BsAtHome No worries, I’d probably feel the same way, just thought I’d ask. Hopefully someone takes good notes at least :) |
|
On So, 2026-09-27 at 03:34 -0700, Greg Carl wrote:
@BsAtHome [1] No worries, I’d probably feel the same way, just
thought I’d ask. Hopefully someone takes good notes at least :)
I did take notes on some meetings I attended and posted them on the
wiki, but there is nothing really substantial in the notes.
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MeetingMinutes-2025-11-23
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MeetingMinutes-2026-01-04
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MeetingMinutes-2026-03-01
[1] @BsAtHome https://github.com/BsAtHome
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
According to our bi-weekly schedule alternating between "early" and "late", this video meeting is next Sunday 2026-Sep-27 at 20:00 CEST.
https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
Access code: 869782
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&month=9&day=27&hour=18&min=0&sec=0&p1=319&p2=236&p3=240&p4=136&p5=165&p6=256
I will not be able to attend this one. Anything on my PRs can go in the PR threads and I will pick it up the next day. Please write the conclusions into this agenda as usual.
Agenda
hal_procs_lib.tclnetlist,halconfig.tcl), both fixed; Tcl 8.6 still uses a 32-bit internal representation (64-bit only in Tcl 9), so Tcl configs deserve a look.~pre2version bump and tag. @BsAtHome holds the bump for the docs PR and wants to tag the tree once all the changes are in, so the CI packages carry the right version. See also item 7.halfileupdate) is draft until the renaming is settled, which hal: Break the HAL API - Move to 64-bit exclusively #4565 settles. Same for hal: Add halcompupdate to migrate .comp files to the new HAL API #4256 (halcompupdate). Do we want these in before or right after the break so users are not left without a converter?.mbccbfiles need recompiling from.mbccsafter the break; where do we tell users (release notes, NEWS, docs)?hal_[gs]et_[us]i32()remain, the tree is not 64-bit clean yet. That is the third phase from last meeting; who takes which components?Conclusion: Merge other first, fix conflicts and then merge.
lut5.0.functionand hm2raw.write-dataare out of the argument: a param and a debug hatch, neither netted.sint. A u64 register keeps every bit on a signed pin; whatuintbuys is semantics and a guard at protocol boundaries (hm2_modbus register images, andcia402.compnetting the CiA 402 statusword and controlword as bit patterns between two separately maintained components). Do we keepuint?bool/sint/uintmismatch a warning instead of an error, signal type still fixed bynewsigor the first pin ofnet, never following later pins. @BsAtHome is not against it; agreed in the thread that the converters stay and that the writer-flag clamp idea is dropped.hal_get_bool()reads_bwhilehal_set_bool()writes_u, so on a big-endian machine every bool reads false. The double negation over the full word that the cross-net change needs also fixes this.conv_real_*converters getreplace_nan/replace_inf_positive/replace_inf_negativepins,clamp_disappears from the real to int direction because there is no wrap to offer, and @BsAtHome proposes the conversion components stop being generated and become static. @rene-dev's FPU invalid-operation flag catches conversions and ordered comparisons but not a NaN that is only copied. Who writes which piece, and does any of it block hal: Break the HAL API - Move to 64-bit exclusively #4565?Conclusion: In principle alright. Needs documentation and some extra discussion.
rip-and-test(or more) a hard requirement, or keep CI as a strong signal with an escape hatch for infrastructure flakes? Also consideration withe some devs discontent see qtplasmac: fix conversational circle M3 vs M03 bug #4580 and Chris on the mailing list. @snowgoer540 posted a long comment here on process: rules applied retroactively and selectively, the per-area maintainer precedent, and how Chris has been treated. He cannot attend. Whatever we decide about CI gates, that part deserves an answer in the meeting, not just in the thread.Conclusion: CI enforcement off. Branch protection: off fir now (politics), but technically, we need to have it enabled. Needs discussion.
Conclusion: Move to include is decided. Will be done after 64-bit move.
Gtk.GLAreawithout the GLX dlopen hack; @alex-pres reports pncconf and gremlin run on Weston with it, which makes Wayland fix (namely pncconf's sample panel) #4523 unnecessary (and answers issue PYOPENGL_PLATFORM=glx must be set if using Wayland (pncconf) #4522). The remaining X11-only pieces are GtkSocket in gmoccapy and everything Tk. Do we want a tracking issue for native Wayland?Conclusion: merged.
Conclusion: Split noted in PR.
VERSION_BASEanddebian/changelog-basestay untouched in git,scripts/create-versionanddebian/create-changeloggenerate the real files, anddebian/update-dch-from-git,scripts/get-version-from-git,scripts/githelper.sh,scripts/get-deb-component-from-gitandscripts/version-is-releasego away. A tag that disagrees withVERSION_BASEalready fails the build; otherwise the version isVERSION_BASEplus count plus hash, counted from the matching tag when there is one and from the lastVERSION_BASEchange when there is not. Local builds then report the full version too. It needs sign-off from whoever runs the releases (@andypugh). Open points for the meeting:VERSION_BASEchange? Failing the build would be consistent, but it leaves master red until someone with tag rights shows up, and pushing the tag before the commit is the only other order. @hdiethelm is checking what GitHub allows; the normal path (merge the PR, get2.10.0-pre2-0-g161d9a34, then push the tag and get2.10.0-pre2) works, but a tag pushed while the commit is still on a branch would publish a release from that branch.2.10.0-pre1because CI replaced the tilde anyway. Keep the Debian-style~pre1and convert, or settle on the dash everywhere including the tags?v2.10.0~pre1tag: create it retroactively so the count has a base, or let the~pre2bump in item 1 carry the fix? Related: the 2.9 merge b6513d0 touched VERSION for a newline, which @BsAtHome considers a mistake to undo.scripts/create-releaseand a release-process page in the Developer Manual. Is that the shape we want, and do we backport it to 2.9?Conclusion: We need streamlining. This process is in the right direction. Details need to be discussed (old release doc: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ReleaseCheckList).
recvpoll forppoll, which cut CPU load, and it added the message that makes a timeout visible, so the bisect may be a false positive. @pcw-mesa reproduces a timeout per second with deliberate packet loss and sees no practical harm. There are test branches for anyone who can reproduce the original report. @hdiethelm offers to join the meeting. Questions: what is the intended behavior on a dropped packet, how loud should the message be, and does this hold anything for 2.10?Conclusion: Configs and logs need to be exchanged to detail where the fault starts. Needs to be run with real hardware. Rene/Robert/Andy will advance this.
HOME_ABORTindexes through a pointer that is already offset, so an abort from joint N stops joints N and up, and past eight joints it writes off the end of the array. Independent of the other two.HOME_SEQUENCEonly synchronized the final move, so search, back-off and latch ran per joint and each leg racked the frame. This runs every leg of the group together.HOME_SEARCH_DISTandHOME_LATCH_DISTand returns from a failed latch.HOME_OFFSETis doing double duty and is not documented as the code behaves, which blocks absolute-encoder machines that also have home switches, I'll work on that once these settle.Conclusion: Andy will take point on this.
[XHC_HB04_BUTTONS]keys likestart-pause) and the pendant comp's own layout cfg files ([XHC-HB04]section). @BsAtHome: dropping the dash was intentional, the pendant was missed. Options: accept the dash again (inifile: accept dash in section and variable identifiers #4573 restores the old behavior, currently draft), or deliberately rename all pendant identifiers to underscores with migration coverage for INI keys, layout cfg files and HAL pin names (xhc-hb04.button-start-pause), in line with the other 2.10 breaks (hal: Break the HAL API - Move to 64-bit exclusively #4565). Decide direction. This also gates Remove Tcl from sample configs #4524: the pendant configs are the first Tcl-generated ones to flatten, that is where the dash question came up, and the flattening is on hold until this is settled.Conclusion: We keep the strict identifier enforcement of
[a-zA-Z_][a-zA-Z0-9_]*. Updates are required to the in-tree files and code. Additionally,update_inineeds to see if this is used and attempt an automated update.See PRs for merge/comments.
Conclusion: Andy will look at this.
Error()now goes through the normal reporter. Ready from my side.initf hm2_eth.realtime-initno longer needed. Two-board case untested. hm2_eth: Create support library's #4498 (hm2_eth support libraries) is the design discussion with @BsAtHome about exporting the API from the existing posix/xenomai libraries instead of new .so files.os._exit()concern addressed, timer gone. Ready to merge.[AXIS_<letter>] TYPEhonored in the interpreter, canon and motion, plus a new[TRAJ] FEED_AXES. @BsAtHome's header points addressed;TYPE = ANGULARon X, Y or Z is now refused at interpreter init, where before only AXIS read the key and nothing validated it. Hand-written configs that set TYPE against the letter change behavior or stop loading, so it carriesbreaking-changeand wants a line in the 2.10 release notes.All reactions