Open ghost opened 4 years ago
It is encouraged. Really, please, do as much as possible, we need help!
I'm sad to say that, but usually, everything that touches memory management is hard to refactor. Also, struct ident
and correlated things are dangerous.
I may add: avoid touching, for now, buffer stuff, or you'll need a major refactoring to keep current behavior.
*maximum size of refactoring PRs
None? As long as you keeep single patches as easy to read as possible? As usual, atomic commits are the easier ones, especially for refactoring.
It would be really appreciated if you could have those separated. Really.
As far as I'm concerned, I don't enjoy github. So, if I can reduce my interactions with it, it's better. We are also not a lot to contribute to this project, and IRC is sometimes easier to use that "login>>write>>oh this changed, rewrite>> oh someone replyed>>etc".... you got the idea. We have peer review and CI for that after all. And we still intend to stay RE1.x compatible. We, on the other hand, have a forum on https://blue-nebula.org feel free to join us :)
What do you mean?
I think the project should encourage refactoring because :
Things that could be somewhat quick, easy and worth to refactor are :
When all these things done, it will be way easier to refactor the architecture itself.
I would submit 1 PR per refactored feature, any amount of commit; for example to prevent spending 1 week refactoring 200 lines in 5 different files, then pushing, then have to deal with lots of code conflicts (refactor changes the code a lot), that would frustrate everyone. Also quicker to review and test, less scary to merge.
Before adding a feature / fixing a bug, I would :
I think refactors should be approved first to avoid spending too much time on something that risk being declined, demotivating all sides.
Minimum code quality for it to be considered as a refactor : if someone is going to refactor something, he better doing 100%, and not partially, because it would cause even more complicated code by having more ways of doing the same thing.
Game is a masterpiece but its code is twisted as hell.
I think it would be a good thing for health of the project to refactor stuff when we have opportunity to.
However the project is currently lacking guidelines about this. This ticket is to discuss and debate about these guidelines. Here's some example points :
Once these guidelines completed, that will prevent people from working hours on a PR that will get refused for X reason, as well as motivate people to refactor code because they will be aware of what they are getting into.