Re: [GSoC PATCH 00/16] Microproject: avoid suppressing git's exit code
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 30, 2026, 15:00 UTC
- Message-ID
- <xmqqbjg5fjls.fsf@gitster.g>
- In-Reply-To
- <ftwnrutdbvyf7phr4ad76agt2jvzgieqnxprvmoyw2vzwbhgqy@z4x2g2n3ft4r>
Trieu Huynh <vikingtc4@gmail.com> writes:
> Ack, I missed that point. Could you clarify how many patches or > files changed are considered appropriate for the microproject?
The end product (i.e., a patch that could be applied to my tree) of a microproject is not expected to have any value to improve the project codebase. The process has two objectives. One is to help new people experience the end-to-end process of sending their first patch, getting it reviewed, engaging in a dialog with the reviewer and communicating with others in the community, and polishing and resubmitting the patch. And the other is to help us see how well each candidate can work with reviewers and others in the community.
The size of a microproject submission to allow us achieve the two goals may ideally be one-liner change ;-) but it may be a bit too hard to gauge the effectiveness of the candidate with such a small patch, so in practice the lower bound would be a single file with a few hunks, with two paragraphs in the proposed log message.
And we certainly do not need 16-patch series, each doing very similar things and likely to be making similar mistakes at the same time. Interactions with reviewers on just one patch would be sufficient for them to learn the community norm, and for us to gauge how effective the canidate is, without doing the same or similar exchanges for the other 15 patches.