All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Anderson <sean.anderson@linux.dev>
To: Jakub Kicinski <kuba@kernel.org>, Daniel Golle <daniel@makrotopia.org>
Cc: netdev-driver-reviewers@vger.kernel.org, netdev@vger.kernel.org,
	Maxime Chevallier <maxime.chevallier@bootlin.com>,
	Russell King <linux@armlinux.org.uk>,
	Christian Marangi <ansuelsmth@gmail.com>
Subject: Re: [ANN] netdev call - Aug 12th
Date: Tue, 12 Aug 2025 11:39:04 -0400	[thread overview]
Message-ID: <b2ce5d8f-139b-4460-bc01-1d6e348ec31a@linux.dev> (raw)
In-Reply-To: <20250812082920.26bae903@kernel.org>

On 8/12/25 11:29, Jakub Kicinski wrote:
> On Tue, 12 Aug 2025 16:16:53 +0100 Daniel Golle wrote:
>> On Tue, Aug 12, 2025 at 07:55:10AM -0700, Jakub Kicinski wrote:
>> > The bi-weekly call is scheduled for tomorrow at 8:30 am (PT) / 
>> > 5:30 pm (~EU), at https://bbb.lwn.net/rooms/ldm-chf-zxx-we7/join
>> > 
>> > Sorry for the late announcement, I got out of the habit of sending
>> > these. Luckily Daniel pinged.
>> > 
>> > Daniel do you think it still makes sense to talk about the PCS driver,
>> > or did folks assume the that call is not happning?  
>> 
>> It could make sense to talk about it, but maybe we talk about other
>> topics first to Sean can join us as well. However, I think mostly we
>> depend on Russell or someone else to make a decision in terms of how the
>> three of us (Christian, Sean and I) should continue.
> 
> Well, then I'm not sure if a meeting is the right approach in the first
> place. Perhaps it's just my feeling but in corporate world managers call
> meetings to force a decision (conclave-style). Upstream we force
> decisions by having patches ready to be merged on the list.
> 
> I would like to avoid anyone ever feeling obligated to join a meeting
> as part of their upstream work.

Personally, I am willing to swap things around as necessary, but I haven't
gotten that impression from Daniel/Christian. I have provided feedback on
Christian's series, but I haven't gotten the follow-up discussion I was
looking for. I think there may be a perception that Russell needs to make
a decision, but I think it would be better for us to come to an agreement
about the best architecture.

I think at this point I (and hopefully Daniel/Christian) have a good idea
of the strengths/limitations of our proposed implementations. I would like
to meet and discuss the best path forward in terms of how we want to solve
the problems. I would also appreciate input from the netdev maintainers who
may have broader experience and perspectives (and who are likely to spend
the most time interacting with whatever solution we come up with).

--Sean

  reply	other threads:[~2025-08-12 15:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-12 14:55 [ANN] netdev call - Aug 12th Jakub Kicinski
2025-08-12 15:05 ` Sean Anderson
2025-08-12 15:16 ` Daniel Golle
2025-08-12 15:29   ` Jakub Kicinski
2025-08-12 15:39     ` Sean Anderson [this message]
2025-08-12 16:45 ` Russell King (Oracle)
2025-08-12 16:57   ` Daniel Golle
2025-08-12 17:15     ` Russell King (Oracle)
2025-08-12 17:45       ` Jakub Kicinski
2025-08-12 17:50       ` Sean Anderson

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=b2ce5d8f-139b-4460-bc01-1d6e348ec31a@linux.dev \
    --to=sean.anderson@linux.dev \
    --cc=ansuelsmth@gmail.com \
    --cc=daniel@makrotopia.org \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev-driver-reviewers@vger.kernel.org \
    --cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.