git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Fix delta integer overflows

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 7, 2017, 21:36 UTC
Message-ID
<xmqqwp6fnjpg.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<alpine.DEB.2.21.1.1708072307410.4271@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 9 quoted lines
> So are you saying that starting with v2.14.0, you accept patches into `pu`
> for which you would previously have required multiple iterations before
> even considering it for `pu`?
>
> Frankly, I am a bit surprised that this obvious change from `unsigned
> long` to `size_t` is not required in this case before queuing, but if the
> rules have changed to lower the bar for patch submissions, I am all for
> it. I always felt that we are wasting contributors' time a little too
> freely and too deliberately.

This is not about where the bar is set. It is about expectation. I do not expect much from occasional (or new) contributors and I try not to demand too much from them. The consequence is that as long as a small patch makes things better without making anything worse, I'd want to be inclusive to encourage them to build obvious improvements on top. Maybe they just want a single patch landed to fix their immediate needs (which may be generic enough and expected to be shared with many other people) without going further, so I may end up queuing something that only helps 40% of people until follow up patches are done to cover the remaining 60% of people, but that is fine as long as the patch does not make things worse (it is not like a patch that helps 40% while hurting the remaining 60% until a follow-up happens).

I would expect a lot more from experienced contributors, when I know they are capable of helping the remaining 60% inside the same series and without requiring too much hand-holding from me. The same thing I cannot say to a occasional (or new) contributor---they may not be coorperative, or they may be willing to do more but may require more help polishing their work than the bandwidth I can afford.

So if you are volunteering to help by either guiding Martin to aim higher and make this a series with a larger and more complete scope, I'd very much appreciate it. Or you can do a follow-up series on top of what Martin posted. Either is fine by me. Just do not step on each others' toes ;-)

I avoided saying all of the above because I didn't want my word taken out of context later to make it sound as if I were belittling the competence of Martin, but you seem to want to force me to say this, so here it is.

Previous: Johannes SchindelinNext: Junio C Hamano
Message 6 of 11 in “Fix delta integer overflows”
  1. Fix delta integer overflowsMartin Koegler, Aug 7, 2017
  2. Junio C HamanoAug 7, 2017
  3. Johannes SchindelinAug 7, 2017
  4. Junio C HamanoAug 7, 2017
  5. Johannes SchindelinAug 7, 2017
  6. Junio C HamanoAug 7, 2017
  7. Junio C HamanoAug 7, 2017
  8. Martin KoeglerAug 8, 2017
  9. Johannes SchindelinAug 8, 2017
  10. Junio C HamanoAug 8, 2017
  11. Martin KoeglerAug 8, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.