Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > Especially as I'm not insisting that I be the one to drive anything > forward on the scalar topic, I think it makes much more sense that it's > Victoria. > > This patch is just offered as a way to help that effort along. Perhaps > she'd ack it as-is, find it useful as it reveals some edge cases she > didn't know about, or drop it and go for some other approach. Whatever > gets us to the end-goal sooner than later is fine by me. Careful ... > Once you "git rm" the scalar Makefile there's not really a lot of ways > you can go other than something approximating the upthread patch. Given > that some of the edge cases are tricky I deemed it worthwhile to share > it. > ... > I'm not saying that, but "you seem to be trying to do X, and may or may > not be aware of a past patch that does X, here is is in case it help!. > ... > Some of the edge cases in the Makefile integration are subtle. I trust > that someone looking at it would probably discover those eventually. ... Even though you ask to assume good intent, an attitude shown by repeated "I've done that, I already know *the* solution to the problem you are trying to solve, and you can learn from what I did" gives recipients quite an impression different from what you intend to give. > But if I'd have gotten a patch from my future self with all the learned > edge cases beforehand I'd have appreciated, so I figured I'd send it in. In any case, if you stop sending *replacement* patches in response to others' work, that alone will reduce the friction people around you are feeling quite a lot. A replacement patch is a horrible and inefficient way to comment on others' work, if your goal is to be understood. The recipient would be forced to read and think like you did, making comparison between the two approaches themselves if they want to see if it is worth to use the replacement. Making comparison between approaches, arguing for the alternative approach to be better, and proposing the alternative to be taken, is the responsibility of the party who is suggesting alternative approaches, not that of the recipient. For that reason, if you want to say something to other people's work, you are better off doing that either by commenting in-line (i.e. annotating their code you want to comment on), or if you absolutely need to talk in code, or by giving an incremental update once their work solidifies (i.e. pointing out a specific issue in the existing code, explaining why it is a problem worth addressing, and offering an update---just like when you are fixing a bug). Thanks.
