On Wed 2024-01-10 15:51:40, Marcos Paulo de Souza wrote: > On Wed, 2024-01-10 at 11:15 -0700, Jonathan Corbet wrote: > > Attreyee M <tintinm2017@xxxxxxxxx> writes: > > > > > Hello maintainers, > > > > > > I wanted to ask if this patch of mine is accepted as of now. > > > > You never responded to the question that is still quoted in your > > (unfortunately top-posted) email: > > > > > So this is a classic example of saying what you have done, but not > > > why. > > > What makes this a change that we want? > > > > So no, not accepted. Even with a proper changelog, though, I'm not > > sure > > I see the value in that particular change. > > >From time to time I see people complaining about the lack of new people > coming to kernel development, IMHO, it is much worse on the maintainers' side. There is a lack of maintainers. And I believe that most of them have hard times to manage the load. They should provide hints. But we could not expect that they would do the work. > and that Documentation would be a good > start for some of them to learn how to send patches by email (which by > itself is difficult...). Attreyee, please read Documentation/process/submitting-patches.rst before you send another version. Also please run scripts/checkpatch.pl before you send the patches. > As Documentation patches aren't backported, why not accept this patch? > > Jon, I understand your reasoning, but I agree with Attreyee here. The > term "acquire" fits better when in conjunction with "released" than > "get". > > Can you show an example of a good commit message to Attreyee so he can > adjust and resend? I'm sure the next time he'll consider remember the > suggestion given and the next patch will have a better commit message. I suggest that Attreyee makes another attempt himself. John explained what was the problem. Attreyee could get inspiration from the git history. Anyway, the commit message simply should explain why "acquire" is better than "get". Best Regards, Petr
