I feel like I need to respond to this. For the most part, I think the “bouncing the rubble” points are spot on. Reorganizing files can have benefits, and generally github is quite good at recognizing the move. But other than that, changing function names/capitalization/etc is kind of pointless and creates more rift/cruft.
But the logical fallacy of regressions being tied to refactorings (correlation does not imply causation) bothers me. Regressions aren’t exclusively caused by refactorings, and I think I’ve seen quite a few caused by moving non-template functions to templates (this causes lots of headaches because testing a template is a much different animal). Sometimes progress reveals mistakes that you learn from, or identifies more issues to be fixed. The on-purpose breaking needs a high bar, and you have discretion there. I have seen a few times recently where you rejected very popular on-purpose breakages that seem for some to make progress, and that’s fine, I defer to your wisdom there, even if I don’t agree. But please don’t consider this to be carelessness or explicit sabotage. Everyone is trying to improve things. And finally, the lamenting about not having everyone working on what you want to do is somewhat insulting. Not everyone has the same goals or dreams, and many of these pull requests come from outside our developer circle. When someone feels passionately about a problem, and submits a fix, I think it’s foolish and damaging to reject that or ignore it simply because it’s not part of the Walter Bright plan. We all have our selfish wants and needs, and that is not a bad thing. We are told day in and day out, if you want something changed in D, please submit a PR. I understand you’re busy, it’s a frequent problem of mine too. There are many things that I think are critical to the success of D that nobody works on. But I don’t complain that nobody listens to me. And to be fair, there have been quite a few pulls generated by others to further your goal of rangifying functions that others have made. Please keep in mind how open source communities work together, this isn’t the same as a for-pay organization. We all agree with your vision for the most part, but not everyone needs to exclusively work on your priorities for D to succeed. Perhaps your rant was directed specifically at certain people/changes. I can’t tell from your post. But I hope you can understand how discouraging this sounds to others, no matter what part of the system they work on. I am really in agreement that we want to prevent needless rubble movement. It’s just the lack of your agenda fulfillment that gets me. Finally, please note that these statements are from ME I don’t represent anyone else. And I’m not trying to cause distress here. I’m merely stating how this sounds to me. Let’s have a beer in Utah and get our goals all aligned :) -Steve > On May 22, 2015, at 6:07 PM, Walter Bright via dmd-internals > <[email protected]> wrote: > > > > On 5/22/2015 10:16 AM, Daniel Murphy wrote: >> Could you please identify some refactorings that you feel are useless? >> I've been the author of many large refactorings needed for DDMD, and >> I suspect you making yourself the bottleneck for refactorings is going >> to be a huge pain. If you feel contributors have been merging pull >> requests without adequate review please let us know. >> > > I have pulled the ones you needed for DDMD, and I pulled them because it was > necessary in order to make DDMD work. > > Of course it's a judgement call, but refactorings that are not productive > share one or more of these characteristics: > > 1. potatoe potahto name changes > 2. indentation/whitespace/reformatting > 3. the number of lines of code increases > 4. re-ordering functions in a file > 5. moving code from one file to another > 6. large diffs with no seeming point to them > 7. large diffs that are not reviewable because github diff is unhelpful with > figuring out what actually changed > 8. make dmd slower > > Essentially, refactorings that "bounce the rubble" around are going to be > viewed negatively. > > Refactorings that would be viewed with favor: > > 1. identifying significant common code sequences out and consolidating into > reusable functions > 2. better encapsulation > 3. more logical flow of control > 4. reduction in cyclomatic complexity > 5. move towards making functions pure > > For example, I recently did a small refactor that replaced argc/argv manual > memory management with the Strings type. It removed a bunch of code, and the > rest flowed a lot better. > > I've pulled a lot of refactorings. My concern with this is the large increase > in regressions. Those refactorings should be reducing regressions - but it > seems that at best they are not helping, and at worst are making things > worse. I'm also concerned that people are not working on the real problems > with DMD, and instead are doing refactorings. We have a lot of open > regressions, and no proposed fixes for them. But we've got refactorings > regularly appearing. I know that refactorings are more fun than regression > fixes. But we've got to get the bread and butter work done. > > And lastly, I am swamped with work. I'm the only one working on range fixes > for Phobos - fixes that I have been advocating for a couple years now, and > nobody has done anything to move this forward. So I am doing it. This > range-ification is, quite frankly, absolutely critical to D's future success. > I must get it done. But I get bogged down in interminable reviews of > refactorings with hundreds of lines of rubble bouncing. > _______________________________________________ > dmd-internals mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-internals _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
