Hi Sébastien, At 2026-04-01T10:03:53+0200, Sébastien Hinderer wrote: > Hey Branden, Thomas, all, > > Many thanks for your reactivity.
A potent word in the discipline of nuclear engineering. ;-) > G. Branden Robinson (2026/04/01 02:33 -0500): > > Okay. As a rule of thumb it's a good idea to have some > > understanding of code patches you submit. Doing so facilitates > > effective communications between developers from different projects > > (and in general). > > I certainly agree. It's just that I did what my current life > circumstances permit, hoping that it would be enough for upstream to > get the intention and do the rest. Not always a vain hope. My advice was a technique for reducing the amount of friction that can afflict patches that seem to reveal a lack of understanding of the system to be modified. > Okay I can try to have a look. Just to clarify, though, are you > talking in a general way, or do you want me to improve this specific > patch and saying that updating the database will not be done unless I > submit a better patch? I'm not saying you have to improve the patch; the gist of it is clear. And I definitely do not insist that you must provide actionable feedback on the terminfo(5) man page before your patch will be considered. That would strike me as an unwarranted and unfair coupling--or contrived pipelining--to me. Any time you see a software developer doing such a thing, you should make note of it and proceed cautiously--allocate your resources of time and energy carefully. (By contrast, it's often worthwhile and even considered a best practice in software engineering to couple code changes with updates to documentation and, ideally, to an automated test suite such that the correct operation of the change is verifiable. In another project, I frequently find myself having to write documentation and automated tests for code changes that other people contribute.) Also, even were I inclined to erect such a hoop for you to jump through, I'm not in a position to do so. Thomas Dickey is the sole ncurses maintainer and, as far as I know, the only person with commit privileges to its development repository. As I understand it, he uses RCS for version control, which means that it's not a "distributed" VCS--the only "official" repository resides on a machine under his control. All changes I've made to ncurses have taken the form of patches proposed to this mailing list, just as yours was, and are subject to his review. While he accepts most of my contributions, I don't have a 100% acceptance rate--that's not even a goal of mine. I asked you to review the beginning of the terminfo(5) page so that you could (1) increase your knowledge in an area that obviously concerns you and (2) so that I, as a contributor to ncurses documentation, can get a newcomer's perspective on the tractability of the material. The two best sorts of people to have working on documentation of a system are a rank novice and a domain expert. The expert knows how things "really work" and the novice can question "obvious" assumptions that the expert has internalized. People who have mastered a system often know it so deeply that they can fail to notice that their fundamental presumptions have failed to make it into the written record. Unfortunately I myself am somewhere between these extremes, and therefore the least useful type of person to be contributing. :-O Regards, Branden
signature.asc
Description: PGP signature
