Deconz-rest-plugin: Git workflow conventions in this project

[dergreg]

I noticed this project uses a couple of non-standard or at least unusual Git workflows that are quite different from other Git(Hub) projects, such as:

• Separate commits for individual files (instead of one commit with all files included)
• As a follow up of the above: The commit message often starts with "Changed some_file.cpp <newline> Added support for device XYZ"
• Merge requests with a lot of commits do not get merged in squashed form, often ending up in lots of commits in the main tree

As a contributor (or just a user building the latest source), it's really hard to see what actually changes within the project when the git log is cluttered up with dozens of individual, single-file commits starting with a meaningless "updated file.cpp" commit message.

Are there any plans to adapt the Git workflow to a more common style as found in other projects?

Regards

[Mimiix]

Hi!

Good to see you open a issue on this. We recently had this discussion on the meeting i had with the devs and DE. They are working on a way and @manup is going to propose a workflow for this.

Any feedback is appreciated, so please spill some if you'd like.

Thanks again!

[aofwer]

@dergreg Thank you so much for raising this question. I was just thinking the very same thing after looking at the commit history.

I am just an average user who is trying to understand the code and the changes to it. With the current state, tracking changes is almost impossible.

First of all I think it's great that this project is so open to changes from the community. I have also noticed that there are very active community members (which are not members of dresden-elektronik) who fix a lot of bugs and implement new features, which is awesome.

I still think this project needs some basic commit/development conventions, just like @dergreg mentioned. To give you some more examples, this is what I am referring to:

• Right now I see a full page of Update release-drafter-config.yml. I know it's hard to get things right the first time, so some fix-up commits are usually fine. But this release-drafter-config thing really clutters the history and things like that should be avoided in the future.

• As mentioned by @dergreg commit messages like "Updated file xy.cpp" are not very helpful. I can see from the commit itself that this file has been changed, I'd like to know why it was changed. Maybe community members could be pointed to https://chris.beams.io/posts/git-commit/ for starters.

• Pull requests sometimes get quite large because multiple things are addressed at once. I guess it would also help the maintainers of this project if one pull request only does one thing at a time (like "Implement support for thermostat xyz"). Multiple commits per PR are fine of course, so squashing is not always required.

• After a PR has been merged I saw comments like "this PR was not ready yet". This should be avoided by either prefixing the PR with something like [WIP] or by marking it as a draft (there's a button for that on Github). This way others can see that somebody is working on a thing but the maintainers know that it's not ready to merge yet.

Again, please don't get me wrong. This is an awesome project with outstanding community members. I am a bit ashamed of myself that I, who has not contributed anything to the codebase yet, is asking others to change their workflows. Please just take it as a suggestion how you can get even better and don't take is as some sort of negative feedback (it definitely is not!).

[Mimiix]

@aofwer That Release drafter thingy is totally on me. It is due to the release drafter action which i can't test any other way. It is as i want it right now, so please forgive me on that ;)

I have put this issue on dev's noses.

[stale[bot]]

As there hasn't been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[dergreg]

Has anything be discussed within the team? Will there be any guidelines for developers and contributors? Thanks.

[stale[bot]]

As there hasn't been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[Mimiix]

@dergreg We did somewhat, but not anything new to mention. Let me drop this again in the group ;)

[stale[bot]]

As there hasn't been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it isn't solved, request to get this opened again.