BMSBattery_S_controllers_firmware
BMSBattery_S_controllers_firmware copied to clipboard
stancecoke
maintainership conversation (and some of my fixes :P)
Hi,
(This is a PR just to bring attention to the bits of generally usable stuff i happened to do while making my bike run, the bigger things i want to talk about follows...)
Reading the comments on an another pull request here, there's nobody interested enough to be the singular maintainer for this.
I'm not signing up for that either, but i think this means we should adjust the collaboration style.
My suggestion is: let's make a branch where everyone interested gets direct push rights, so there's a place to integrate our work together, otherwise there will only be endless forks without much collaboration - mostly because we're not aware of the fixes other people have made on their own forks...
My question is: where (which repo) should we place this? (I'm asking because i'm the new guy here and i don't know what i dont know...)
I raised the same issue here: https://github.com/stancecoke/BMSBattery_S_controllers_firmware/issues/16
I think your solution is brilliant. @stancecoke you can set branch protection rules on master and start giving access more freely to potential contributors who ask for it (this would allow them to push to all other branches but not master). Then indeed we'll be able to collaborate.
I agree with your solution, I'd like to contribute too, but I don't know where. I've started with https://github.com/consp/BMSBattery_S_controllers_firmware/tree/master, which has some nice changes of its own too. But now I realise pullrequests over on another fork is not ideal.
@stancecoke I think it'd really help if you added protection rules to the main branch but gave people commit rights for other branches more freely. Then this repo would be the main one for collaboration. Otherwise, even after a few years, we're still seeing more and more forks…
BTW I reviewed the changes in this PR and everything makes sense. The commit descriptions are a bit angry but I like the energy. 😅 I don't feel good about jars in the repo but this is something that can be fixed later. Overall, good to go! ❤️
I'm not maintaining this project any longer. If someone wants to continue it, feel free. I can add a hint in the readme, which fork is the "Master" now. Or we can go back to @casainhos https://github.com/OpenSourceEBike/ repo.
~~Possibly a project and "organisation"? What do you all think of this idea?~~ Oh, this exists already... Merge into OpenSourceEbike organisation makes sense, but who owns it then? Multi owner/maintainer? How would we go about merging stancecoke:Master and OpenSourceEBike:master? Does seem like a big task to me. And what about the currently open pull-requests? I am interested in merging and resolving conflicts for both this(urjaman's), @MartGB 's #23 and another suite of commits by @consp Consp/BMSBattery_S_controllers_firmware:Master (based on MartGB's changes)
@consp Consp/BMSBattery_S_controllers_firmware:Master (based on MartGB's changes)
Not meant for merging since it's pretty much only meant for my bike. Could cherry-pick some parts of it if there is an active master and someone is willing to review the changes (e.g. the updated map functions, fixed point-ish math instead of floats, LCD8 stuff). The fork will also not likely compile on windows since I altered the makefiles to better work on linux (and switched to a later version of the compiler) and haven't tested on windows. I started out with MatGB's branch since it contained the LCD8 stuff but in the end I completely rewrote that part and merged stuff from other forks as well so that will definitely not merge as smooth as you like. Also redid the structure to be a bit more sane (split headers/source for instance) to be in line with most C programming.
We can grant you write access to the Open E-Bike Organization, but we need someone who will maintain the project.
Not meant for merging since it's pretty much only meant for my bike. Could cherry-pick some parts of it if there is an active master and someone is willing to review the changes (e.g. the updated map functions, fixed point-ish math instead of floats, LCD8 stuff). The fork will also not likely compile on windows since I altered the makefiles to better work on linux (and switched to a later version of the compiler) and haven't tested on windows. I started out with MatGB's branch since it contained the LCD8 stuff but in the end I completely rewrote that part and merged stuff from other forks as well so that will definitely not merge as smooth as you like. Also redid the structure to be a bit more sane (split headers/source for instance) to be in line with most C programming.
I've changed windows building to work with the sane file structure which is way better. I made a pullrequest to your fork for it but understand that is not really the way to merge the overal project. Cherrypicking certain files of certain commits will be a lot of work but possibly worth it. Cherrypicking commits and merging different pullrequests might be the way, but is a very large and messy task.
I made a pullrequest to your fork for it but understand that is not really the way to merge the overal project.
Ah , hadn't noticed it, for some reason github didn't show it (or I clicked it away sorry).
herrypicking certain files of certain commits will be a lot of work but possibly worth it.
My idea was more to select the generally useful improvements and copy/paste them into a new branch, shouldn't be too hard but indeed a bit of work.
My idea was more to select the generally useful improvements and copy/paste them into a new branch, shouldn't be too hard but indeed a bit of work.
Much easier, you don't care about receiving credit / maintaining commit history?
Much easier, you don't care about receiving credit / maintaining commit history?
final changes are "credit" and commit history ... mwa, mostly my mistakes so they can be erased. The orignal branch still exists for all it's relative glory. If I have to chose less work vs "credit" i'll chose less work, credit is generally meaningless. If someone needs it for their job sure go ahead but in my case that won't apply.