Re: [GSoC] Introduction
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Feb 25, 2019, 21:09 UTC
- Message-ID
- <CAPig+cSZZaCT0G3hysmjn_tNvZmYGp=5cXpZHkdphbWXnONSVQ@mail.gmail.com>
- In-Reply-To
- <CAP8UFD1wK+goi1rKGjABcs01VwYw2kEma95n08H1EWVT4vh6ng@mail.gmail.com>
On Mon, Feb 25, 2019 at 3:22 PM Christian Couder <christian.couder@gmail.com> wrote:
Show 10 quoted lines
> On Mon, Feb 25, 2019 at 12:36 PM Rohit Ashiwal > <rohit.ashiwal265@gmail.com> wrote: > > I don't think I quite understood this. Were you asking for replacing > > all `test -X` calls with `test_path_is_*` calls in only one tXXXX-*.sh > > file or `test -d` calls with `test_path_is_dir` in all tXXXX-*.sh? As > > of now, I've changed almost all `test -d` in all relevant tXXXX-*.sh > > files. > > So yes I am asking for replacing all `test -X` calls with > `test_path_is_*` calls in only one tXXXX-*.sh file.
Not stated outright, but an important reason for limiting the scope of this change (and, indeed, the scope of any patch series) is to ease the burden on people who review your submission. Large patch series tend to tax reviewers heavily, even (and often) when repetitive and simple, like replacing `test -d` with `test_path_is_dir()`. The shorter and more concise a patch series is, the more likely that it will receive quality reviews.
Another reason for keeping the scope of changes limited is to ease the burden of the project maintainer. Patch series which touch a lot of areas tend to conflict with in-flight topics from other people, and the project maintainer has to juggle and resolve these problems. Concise patch series, on the other hand, are less likely to conflict with changes elsewhere.