Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 10 Dec 2022 06:24:26 +0900
From:   Dominique Martinet <asmadeus@codewreck.org>
To:     Christian Schoenebeck <linux_oss@crudebyte.com>
Cc:     Stephen Rothwell <sfr@canb.auug.org.au>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: build failure after merge of the v9fs tree
Message-ID: <Y5OnimhNCFGVYvrq@codewreck.org>
References: <20221205150316.6fac25f2@canb.auug.org.au>
 <6054083.7yRespAWZ4@silver>
 <Y5J4/5WGnG5Uxadg@codewreck.org>
 <3078112.XLg7Fjt2ba@silver>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <3078112.XLg7Fjt2ba@silver>
Precedence: bulk

Christian Schoenebeck wrote on Fri, Dec 09, 2022 at 03:40:06PM +0100:
> > > You remember updating the 1st patch as well, right? :)
> > 
> > It looks up to date to me, e.g. zc is added at the end of the p9_fcall
> > structure.
> > (and these are the only two patches you sent, right? :D)
> 
> Mmm, that's the queued patch I see:
> https://github.com/martinetd/linux/commit/298468c26c14682a5be80a6ec1b4880c8eb3b261
> 
> Which is v1 ('zc' is not at the end of the structure, and in v1 there were
> multiple assignment in the same line like:
> 
>   req->tc.zc = req->rc.zc = false;
> 
> which caused code style checker to bark (as well as on the commit log which it
> found too short). So in v2 it is:
> 
>   req->tc.zc = false;
>   req->rc.zc = false;
> 
> And yes, only two patches. :)

Ah. . . what did I just say about applying patches in my local branch
for testing later, they correct one is just sitting there but wasn't
tested/pushed yet :/

(if you care, I'm using my 9p-test branch for that, but it's not sent
sent to -next obviously)


> Well, workflows are quite different. Personally I always manually reply to
> mailed patches once I queued them, so that people can verify and correct me in
> case I queued the wrong ones. I never had the feeling to script that part.

Yes I usually do write a note about it when I take the patch locally,
but in this case I think I just applied the patches for checkpatch
(indentation looked off without being sure it'd complain) and didn't
intend to queue it; then came back later and "oh they're here, thanks
past me!" (incorrectly)

I guess at this point the problem comes back down to not running
tests/pushing to next immediately; if I finish automating that part I
think this kind of errors wouldn't happen as non-pushed patches wouldn't
make sense...
Well, it's been rare enough but still worth thinking about safeguards
imo, there's usually a reason for v2 patchs so getting the v1 in even
occasionally is bad :-D

-- 
Dominique