patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Josh Soref <jsoref@gmail.com>
To: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Cc: dpdk stable <stable@dpdk.org>
Subject: Re: please help backporting some patches to stable release 19.11.12 - part II
Date: Wed, 9 Mar 2022 07:47:01 -0500	[thread overview]
Message-ID: <CACZqfqDS=yGxm8FFaVqUER_rfdoR9HP0zocqaTz0xnv0-fFzpg@mail.gmail.com> (raw)
In-Reply-To: <CAATJJ0LiMHrqUE+m2L3BNoPwwpcUYVAyr8A_sua+U-1Wrrd6WA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]

On Wed, Mar 9, 2022, 2:49 AM Christian Ehrhardt <
christian.ehrhardt@canonical.com> wrote:

> On Fri, Feb 25, 2022 at 6:54 PM Josh Soref <jsoref@gmail.com> wrote:
> >
> > Christian Ehrhardt wrote:
> >
> > Hi commit authors (and maintainers),
> >
> > Despite being selected by the DPDK maintenance tool
> ./devtools/git-log-fixes.sh
> > I didn't apply following commits from DPDK main to 19.11
> > stable branch, as conflicts or build errors occur.
> >
> > Can authors check your patches in the following list and either:
> >     - Backport your patches to the 19.11 branch, or
> >     - Indicate that the patch should not be backported
> >
> >
> > My spelling work can be safely skipped.
>
> Thank you for the FYI
>
> Maybe to everyone let me explain the reason why we even try :-)
> In general those kinds of fixes are not "too important" but if they
> can be applied it keeps the amount of extra churn lower later on.
> Imagine you touch every string with a commit, afterwards nothing will
> apply automatically anymore.
> So sometimes backporting those changes even if they feel "not
> important" can help.
>

Fair. Perhaps my message was a bit flippant. In general my changes are both
not important and also fairly easy to backport. If you need help, I could
probably allocate time to do it.

I've recently grown to love Visual Studio Code's conflict handling. If my
commits still have the original commit message (can't remember if they do
here, probably not, but I could start from the branch that did), while
rebasing I can select the word that the commit says was the replacement in
the `>>>>>> spelling: ...` line, and it'll highlight the matches within the
`<<<<<<` / `========` parts, and then I can visually identity which aren't
in the former and copy up the fixes from the lower part. And then I click
the accept link to keep the top part.

>

[-- Attachment #2: Type: text/html, Size: 2688 bytes --]

  reply	other threads:[~2022-03-09 12:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220225171532.3498996-1-christian.ehrhardt@canonical.com>
2022-02-25 17:53 ` Josh Soref
2022-03-09  7:49   ` Christian Ehrhardt
2022-03-09 12:47     ` Josh Soref [this message]
2022-03-07 15:15 ` Kalesh Anakkur Purayil
2022-03-09  7:53   ` Christian Ehrhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACZqfqDS=yGxm8FFaVqUER_rfdoR9HP0zocqaTz0xnv0-fFzpg@mail.gmail.com' \
    --to=jsoref@gmail.com \
    --cc=christian.ehrhardt@canonical.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).