Open Stack

TL/DR: I think you're trying to solve the problem the wrong way. If you're
trying to reduce the burden of large patches, I feel the project in
question should distribute the burden of reviewing the big ones so one
person's not stuck doing them all. That also means you can keep that patch
in mental context.

Also, random concerns I have with using "Line of code" as a metric:

* What counts as a Line of Code? Does whitespace count? Comments? Docs?
Tests? Should comments/docs/tests be included in this heuristic?
* Taking a big patch, and splitting it into several, can easily lead to
dead code as the first patch may remain completely inactive on master until
the entire patch chain merges.
* git annotate becomes far less useful, as you cannot simply look at all
the applicable changes for a given patch - you have to dig for all related
patches.
* Reverting things becomes more difficult for the same reason. Would you
revert all-in-one? One revert per patch?

I've seen, and written, 1000+ line patches. Some of them were 200 lines of
logic, 1000+ lines of tests. Others included extensive documentation,
comments, etc, or perhaps-too-verbose parameter and method names that
clearly explain what they do. Others use method-parameter-per-line style
formatting in their code to assist in legibility.

While I totally understand how frustrating it is to have to review a large
patch, I'm not in favor of a hard limit for something which is governed
mostly by whitespace and formatting preferences.

Michael

On Tue, Dec 1, 2015 at 6:36 AM Sylwester Brzeczkowski <
sbrzeczkowski at mirantis.com> wrote:

> Neil, just to clarify: moved/renamed files are marked as "R" so I think
> there may be some way to ignore such files when counting LOC.
>
> Maciej, I completely agree with you. It's pretty hard to review such big
> change,and takes a lot of time which could be saved by submitting smaller
> patches.
>
> +1
>
> On Tue, Dec 1, 2015 at 1:50 PM, Neil Jerram <Neil.Jerram at metaswitch.com>
> wrote:
>
>> On 01/12/15 12:45, Maciej Kwiek wrote:
>> > Hi,
>> >
>> > I recently noticed the influx of big patches hitting Gerrit
>> > (especially in fuel-web, but I also heard that there was a couple of
>> > big ones in library). I think that patches that have 1000 LOC are
>> > simply too big to review thoroughly and reliably.
>> >
>> > I would argue that there should be a limit to patch size, either a
>> > soft one (i.e. written down in contributor guidelines) or a hard one
>> > (e.g. enforced by gate job).
>> >
>> > I think that we need a discussion whether we really need this limit,
>> > what should it be, and how to enforce it.
>> >
>> > I personally think that most patches that are over 400 LOC could be
>> > easily split into at least two smaller changes.
>> >
>> > Regarding the limit enforcement - I think we should go with the soft
>> > limit, with X LOC written as a guideline and giving the reviewers a
>> > possibility to give -1s to patches that are too big, but also giving
>> > the possibility to merge bigger changes if it's absolutely necessary
>> > (in really rare cases the changes simply cannot be split). We may mix
>> > in the hard limit for ridiculously large patches (twice the "soft
>> > limit" would be good in my opinion), so the gate would automatically
>> > reject such patches, forcing contributor to split his patch.
>> >
>> > Please share your thoughts on this.
>>
>> I think most of your principle is correct.  However I can imagine a file
>> renaming / moving patch that would appear in Gerrit to be >=1000 LOC,
>> but would actually just be file moves, with perhaps some trivial changes
>> to Python module paths; and I don't think it would be helpful to force a
>> patch like that to be split up.  So it may not be correct to enforce a
>> hard limit all the time.
>>
>>     Neil
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> *Sylwester Brzeczkowski*
> Junior Python Software Engineer
> Product Development-Core : Product Engineering
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151201/dfd2927c/attachment.html>