[openstack-dev] [Fuel] Patch size limit

Sergii Golovatiuk sgolovatiuk at mirantis.com
Tue Dec 1 19:48:58 UTC 2015


Hi,


On Tue, Dec 1, 2015 at 5:41 PM, Michael Krotscheck <krotscheck at gmail.com>
wrote:

> 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?
>

Comments/tests can be easily excluded from scope of LOC calculation. The
number of lines may be negotiated with community. Rally has 500 lines limit
in CI. Fuel community may vote for 600 or for 400 and change it later. It's
not static.

* 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.
>

Dependent patches on gerrit is a good sample how big patch should be split.
Some of them can break CI though the chain gives better view than one
massive patch.


> * 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?
>

It's just a strategy. Usually revert all-in-one works. However, I saw when
patch in the middle was reverted.


> 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.
>

There are some cases when patch cannot be split. However, Core reviewer may
merge with -1 from CI LOC job in that case. Also the author may specify in
commit message why the patch cannot be split. Though in that case it will
be author's responsibility to prove the necessity.


> 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
>>
>
> __________________________________________________________________________
> 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/13f9a3b0/attachment.html>


More information about the OpenStack-dev mailing list