Hey Igor! Thank you for the response!
On 7 December 2015 at 12:03, Igor Kalnitsky wrote:
> Hey Andrii,
>
> I'm totally agree with you about contribution guides, except one thing
> - we need and should force users to split huge patches into set of
> small ones.
>
I believe that this is much more
On Mon, Dec 7, 2015 at 3:32 AM Roman Prykhodchenko wrote:
> Maciej, thanks for bringing this topic up for the discussion!
>
> I absolutely agree with the idea that at this point we have a problem with
> patch size. Patches that are too big usually have two major issues: they
> either don’t get re
Following up on my previous email:
Every blueprint specification has a Work items section. That section should
describe granular work items, not just things in general. We should encourage
components leads to put their attention to this aspect.
> 7 груд. 2015 р. о 12:23 Roman Prykhodchenko н
Maciej, thanks for bringing this topic up for the discussion!
I absolutely agree with the idea that at this point we have a problem with
patch size. Patches that are too big usually have two major issues: they either
don’t get reviewed for a very long time or get random +1s from people who don’t
On 7 December 2015 at 12:20, Sergii Golovatiuk
wrote:
> Hi,
>
> On Mon, Dec 7, 2015 at 2:28 AM, Andrey Tykhonov
> wrote:
>
>> I believe this is against the code review guidelines.
>>
>> «Comments must be meaningful and should help an author to change the
>> code the right way.» [1]
>>
>
> Could
> What if you're not sure how the improved code should look like, but
> you definitely sure that it shouldn't look like proposed one? :)
I believe you should ask other people if you are right, as set '-1' to code
that you
cannot improve is not the best option, so
> If you are not sure how the im
Hi,
On Mon, Dec 7, 2015 at 2:28 AM, Andrey Tykhonov
wrote:
> I believe this is against the code review guidelines.
>
> «Comments must be meaningful and should help an author to change the
> code the right way.» [1]
>
Could you provide a link that accessible by community? Thanks a lot in
advance
Hey Andrii,
I'm totally agree with you about contribution guides, except one thing
- we need and should force users to split huge patches into set of
small ones. Mostly because it will simplify support and review of
patches. Previously we ignored this rule pretty often, and get a lot
of troubles d
I believe this is against the code review guidelines.
«Comments must be meaningful and should help an author to change the
code the right way.» [1]
If you get a comment that says «split this change into the smaller
commit» I'm sorry, but it doesn't help at all.
«Leave constructive comments
Not
Hey folks,
I agree that patches must be as small as possible. I believe it will
significantly increase our review experience - more fast review, and,
therefore, landing to master.
However, I don't agree that we should introduce criteria based on LOC,
because of mentioned reasons above. I believe
Hi,
On Tue, Dec 1, 2015 at 5:41 PM, Michael Krotscheck
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 no
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
Hi Maciej, thank you for bringing this up,
+1, but we should discuss the limit, personally for me it's ok to review
400loc patches,
if the patch covers only one bug-fix/feature implementation.
So if everybody is agree, we should:
1. update contribution guide
2. create a task for *non-voting* gate
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
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.
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 pa
16 matches
Mail list logo
