Date:   Fri, 09 Dec 2022 15:40:06 +0100
From:   Christian Schoenebeck <linux_oss@...debyte.com>
To:     Dominique Martinet <asmadeus@...ewreck.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the v9fs tree

On Friday, December 9, 2022 12:53:35 AM CET Dominique Martinet wrote:
> Christian Schoenebeck wrote on Thu, Dec 08, 2022 at 04:55:17PM +0100:
> > On Monday, December 5, 2022 11:41:55 PM CET Dominique Martinet wrote:
> > > Christian Schoenebeck wrote on Mon, Dec 05, 2022 at 09:40:06PM +0100:
> > > > Dominique, looking at your 9p queue, I just realized what happened here: I 
> > > > posted a v2 of these two patches, which got lost for some reason:
> > > > 
> > > > https://lore.kernel.org/all/cover.1669144861.git.linux_oss@crudebyte.com/
> > > > 
> > > > The currently queued 1st patch is still v1 as well.
> > > 
> > > Oh. Now how did I manage that one..
> > > Thanks for the catch, and v2 had the valid printf modifier...
> > 
> > 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. :)

> > In general, I'm sure nobody complains about extra noise like "queued on...".
> > Then it's also more likely for other people to get which patches are still
> > pending or unseen.
> 
> I usually apply the patch locally when writing a note about 'taking the
> patch for x' -- but the problem is my workflow is pretty manual to say
> the least (piping mail to base64, base64 to git am on another
> machine...); and I'm not always taking the time to run tests immediately
> so not pushing right away to -next, so I assume I took your patches
> early and looked back when testing after you sent v2 and they were there
> so did't notice :/
> 
> I guess I need to pull the tree back and script a reply from the last
> link or something; so you'll notice the reply is on v1 in this case?
> but it'll be a pain to get the subject back like e.g. pwbot does for
> netdev... hmm..
> I'll think about what I can do.

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.

There are also people that use tools to keep track of all incoming patches,
e.g. patchwork client (either the CLI tool, or the web interface):
https://patchwork.readthedocs.io/en/latest/usage/clients/

The advantage is that it can take care about submitted versions and you just
mark queued series as done. If you don't have an account it is read-only, so
you can view pending patches, their status, automatically apply them, but for
changing their official status somebody has to create an account for you:
https://lore.kernel.org/all/2915273.dLz0rCdnKo@silver/

There are various patchwork hosts. Not sure who is responsible for creating
patchwork accounts on lore.kernel.org.

The Redhat guys are using Patchew, e.g.:
https://patchew.org/QEMU/

Powered by blists - more mailing lists