[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dealing with upstream issues

From: Maxime Devos
Subject: Re: Dealing with upstream issues
Date: Mon, 27 Jun 2022 12:30:48 +0200
User-agent: Evolution 3.38.3-1

Ludovic Courtès schreef op ma 27-06-2022 om 12:10 [+0200]:
> Regarding the review process, I think we should strive for a predictable
> process—not requesting work from the submitter beyond what they can
> expect.  Submitters can be expected to follow the written rules¹ and
> perhaps a few more rules (for example, I don’t think we’ve documented
> the fact that #:tests? #f is a last resort and should come with a
> comment). 
> However, following that principle, we reviewers cannot
> reasonably ask for work beyond that. [...]

We can ask to do send the notice upstream, if it's in the rules (I
consider this to be part of the unwritten rules).  And I don't often
have time for addressing the noticed issues and I have other things to
do as well -- I usually limit myself to just reviewing.  I do not
intend to take up work beyond that.

I also consider them to not be rules as in ‘if they are followed, it
WILL be accepted’ but more guidelines like ‘these things are important,
they usually need to be followed, but it's not exhaustive, at times it
might be discovered the list is incomplete’.

I don't think that patch submitters can reasonably expect reviewers to
do all the work.

Also, previously in discussions about the review process, weren't there
points about a reviewer not having to do everything all at once, they
could choose to review parts they know how to review and have time for
and leave the rest for others?

> Related to that, I think it’s important to have a consistent review
> process.  In other words, we should be equally demanding for all
> patches to avoid bad surprises or a feeling of double standard.

I think I've been consistent in asking to inform upstream of the issues
(*), with no distinction of whether it's a new submitter or an
established one or whatever.

(*) Except for when it's really basic downstream changes, like #:make-
flags #~(list ... #$(cc-for-target)) or a substitute* cc -> TARGET-gcc.


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]