Hi Patrik,

be assured that my e-mail wasn't meant as any kind of complaint about
individual person, and explicitly not you. It wasn't actually a
complaint but just a statement, which you confirmed, that we are lacking
reviewers, and a call for help.

It's an open source project and each participant can only do what they
feel able to do, and they should mostly have fun doing it.

Sorry if my statement was badly worded that it could be misunderstood,
we just need more people reviewing, that the individual ones can do less
work and/or focus on what they prefer to do.

KR, Eric

On 17/08/2020 19:43, Patrik Dufresne wrote:
> Hello Eric,
> 
> I was on vacation the last two weeks and that explains why I did not
> take a look at your Merge Request.
> 
> Your work on rdiff-backup is greatly appreciated and I usually take time
> to review the PR, but I have the feeling you are moving a bit too fast
> for the rest of the developers. Talking for me here, I can't keep up
> with your changes. During the "free" time I have for rdiff-backup, I am
> reviewing your changes instead of fixing bugs. I barely have a couple of
> hours per week to work on the project and I can't afford to review the
> PR in a timely manner all the time. I understand it can be frustrating
> for you and I am open to suggestions.
> 
> For the time being, I will continue reviewing the PR when I have a chance.
> 
> 
> On Thu, Aug 6, 2020 at 1:47 AM Eric L. Zolf <ewl+rdiffbac...@lavar.de
> <mailto:ewl%2brdiffbac...@lavar.de>> wrote:
> 
>     Hi,
> 
>     as the subject says, pull requests can stay for days without review, and
>     I really don't like merging my own PRs without someone having looked
>     over it.
> 
>     Reviewing documentation doesn't require any specific knowledge even if
>     being a native English speaker might be an advantage :-) Just tell the
>     author if you understand what he wrote, and if the language is correct.
> 
>     Reviewing code is more engaged but requires IMHO only some Python coding
>     knowledge and the ability to detect bad coding style, and challenge the
>     author to make sure nothing has been overlooked and everything is
>     properly commented. It doesn't require deep knowledge of the code but
>     can be a great way to gain this knowledge.
> 
>     You only need to review the PR which are _not_ WIP and where the
>     pipeline job was successful (green tick).
> 
>     Thanks, Eric
> 
> 
> 
> -- 
> IKUS Software inc.
> https://www.ikus-soft.com/
> 514-971-6442
> 130 rue Doris
> St-Colomban, QC J5K 1T9
> vcs

Reply via email to