[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230425125511.qro3vql5aivxnxlh@skbuf>
Date: Tue, 25 Apr 2023 15:55:11 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: David Ahern <dsahern@...nel.org>
Cc: netdev@...r.kernel.org,
Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: [PATCH v2 iproute2-next 00/10] Add tc-mqprio and tc-taprio
support for preemptible traffic classes
On Mon, Apr 24, 2023 at 07:47:31PM -0600, David Ahern wrote:
> On 4/22/23 10:59 AM, Vladimir Oltean wrote:
> > Unless there are changes I need to make to the contents of the patches,
> > could you take these from the lists, or is that a no-no?
>
> iproute2 follows the netdev dev model with a main tree for bug fixes and
> -next tree for features. In the future please separate out the patches
> and send with proper targets. If a merge is needed you can state that in
> the cover letter of the set for -next.
I know that the trees are split and it is no coincidence that my patches
were sorted in the correct order. I've been working for 10 months on
this small feature and I was impatient to get it over with, so I wanted
to eliminate one round-trip time if possible (send to "iproute2", ask
for merge, send to "iproute2-next"). I requested this honestly thinking
that there would be no difference to the end result, only less pretentious
in terms of the process. If there is any automation (I didn't see any in
Patchwork at least) or any other reason that would justify the more
pretentious process, then again, my excuses, I plead ignorance and I
will follow it more strictly next time, but I'd also like to know it :)
Powered by blists - more mailing lists