[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP5jrPH1Xn5Sja8wqB_oybrv6mubaP+nhpOjRHN8TCDW2=Auhw@mail.gmail.com>
Date: Mon, 1 May 2023 22:44:22 -0600
From: Max Georgiev <glipus@...il.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: kuba@...nel.org, netdev@...r.kernel.org,
maxime.chevallier@...tlin.com, vladimir.oltean@....com,
richardcochran@...il.com, gerhard@...leder-embedded.com,
thomas.petazzoni@...tlin.com,
Köry Maincent <kory.maincent@...tlin.com>
Subject: Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set
On Mon, May 1, 2023 at 10:35 PM Max Georgiev <glipus@...il.com> wrote:
>
> On Sat, Apr 29, 2023 at 1:45 PM Vadim Fedorenko
> <vadim.fedorenko@...ux.dev> wrote:
> >
> > On 28.04.2023 15:14, Max Georgiev wrote:
> > > On Fri, Apr 28, 2023 at 2:11 AM Köry Maincent <kory.maincent@...tlin.com> wrote:
> > >>
> > >> On Thu, 27 Apr 2023 22:57:27 -0600
> > >> Max Georgiev <glipus@...il.com> wrote:
> > >>
> > >>> Sorry, I'm still learning the kernel patch communication rules.
> > >>> Thank you for guiding me here.
> > >>
> > >> Also, each Linux merging subtree can have its own rules.
> > >> I also, was not aware of net special merging rules:
> > >> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
> > >>
> > >>
> > >>> On Thu, Apr 27, 2023 at 2:43 AM Köry Maincent <kory.maincent@...tlin.com>
> > >>> wrote:
> > >>>>
> > >>>> On Wed, 26 Apr 2023 22:00:43 -0600
> > >>>> Max Georgiev <glipus@...il.com> wrote:
> > >>>>
> > >>>>>
> > >>>>> Thank you for giving it a try!
> > >>>>> I'll drop the RFC tag starting from the next iteration.
> > >>>>
> > >>>> Sorry I didn't know the net-next submission rules. In fact keep the RFC tag
> > >>>> until net-next open again.
> > >>>> http://vger.kernel.org/~davem/net-next.html
> > >>>>
> > >>>> Your patch series don't appear in the cover letter thread:
> > >>>> https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/
> > >>>> I don't know if it comes from your e-mail or just some issue from lore but
> > >>>> could you check it?
> > >>>
> > >>> Could you please elaborate what's missing in the cover letter?
> > >>> Should the cover letter contain the latest version of the patch
> > >>> stack (v4, then v5, etc.) and some description of the differences
> > >>> between the patch versions?
> > >>> Let me look up some written guidance on this.
> > >>
> > >> I don't know how you send your patch series but when you look on your e-mail
> > >> thread the patches are not present:
> > >> https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/
> > >>
> > >> It is way easier to find your patches when you have all the patches of the
> > >> series in the e-mail thread.
> > >>
> > >
> > > Aha, I see the problem now. I guess it has something to do with "--in-reply-to"
> > > git send-email optio or similar options.
> > >
> > >> Here for example they are in the thread:
> > >> https://lore.kernel.org/all/20230406173308.401924-1-kory.maincent@bootlin.com/
> > >>
> > >> Do you use git send-email?
> > >
> > > Yes, I use "git format-patch" to generate individual patch files for
> > > every patch in the
> > > stack, and then I use "git send-email" to send out these patches on-by-one.
> > >
> >
> > The problem is, as Köry has mentioned already, in sending patches one-by-one.
> > You can provide a directory with patches to git send-email and it will take all
> > of them at once. You can try it with --dry-run and check that all pacthes have
> > the same In-Reply-To and References headers.
>
> So the best practice for sending patch stacks is to run "git
> send-email ..." against
> a folder containing the freshly generated patch files!
> Thank you for the guidance!
>
> >
> > > Is there a recommended way to send out stacks of patches?
> >
Is it better this time?
https://lore.kernel.org/netdev/20230502043150.17097-1-glipus@gmail.com/
Powered by blists - more mailing lists