Remove temporary files created in EDS tests #482
Conversation
|
I wanted to merge this, but I suddenly got stage fright: @acolomb what is the practice in canopen wrt. merging vs squash and merge? (I'm sorry that this Q is OT to the PR, do we have any forum for discussing best practices and policies for dev in canopen?) |
|
I don't know of any documented guidelines. I usually apply common sense and what has been known to work well from other projects. That's squash merges with hand-tuning on the commit message. It has the advantage of giving an easy reference to the PR number. Usually the individual commits will be less interesting, but if they are cleanly separated, with good commit messages, and no cleanup was needed during review, I guess rebase-merging is fine, too. |
The Git log shows that merge commits have not been committed the last three years; squashed commits seems to be the prevailing style now, which I 100% fully support. Squashed commits with well-written commit titles/bodies makes for a readable Git history and increased maintainability. |
Probably best to use GitHub's discussion tool for this. But with the currently small base of active contributors, it's not tragic to ask some OT questions within a PR :-) |
|
Following up in the OT track 😄 Is there an instant-messaging forum for CAN/CANopen stuff (Discord or similar)? |
|
Squash merging is an opinionated 🔥 topic . Some love it, other loathe it, so I had to ask. What is "obviously, my friend" one place might not be that in other projects. YMMV. |
I don't know of any, but I'm in 😎 |
|
In general, this project is not as professionally managed, with all kinds of supporting infrastructure, as maybe other, bigger projects. I'm very grateful for all your contributions lately, @erlend-aasland and @sveinse. But I think time is better spent looking at the code and discussing asynchronously via GitHub discussions / issues / PRs, than on setting up some kind of developer hangout. I for one wouldn't have the opportunity to participate there regularly, thus working through notifications as time permits is my preferred workflow. If the question was more generically about CAN and CANopen, not this library, then I don't know of any. That question might best be answered by CiA if they know of any such exchanges. |
|
Sure, I agree with all of that, @acolomb! Sorry, I did not imply that you (or any of the other maintainers) should use time and energy on such things. |
|
Anyway, let me know if you want any other changes before landing this :) |
|
My first merge as maintainer in canopen, so I'm open to feedback if I did anything wrong @acolomb |
|
Congrats on your first merge! I'm curious why you chose a merge commit:
|
|
Oh, damn! Then I actually did fail. My intentions were to do a squash merger and I thought I did, but evidently I did not do that. So that's the rookie mistake then. For that I'm very sorry. 😢 (For the record: I'm not a git or github rookie, just new in this project). |
|
Life's not perfect. Neither is any project's Git history. Let's view it as a minor detail of such small importance that we can forget about it right away :-D Sorry for not participating closely. Things got in the way this afternoon. But good to see we have one more co-maintainer to take care of stuff. |
Clean-up post #474