Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > On Tue, 2024-02-13 at 13:19 +0100, Arend van Spriel wrote: > >> On 2/13/2024 12:45 PM, Johannes Berg wrote: >> > On Tue, 2024-02-13 at 12:13 +0100, Arend van Spriel wrote: >> > > >> > > I recall the rule was that nl80211 API changes >> > > should also have at least one driver implementing it. Guess we let that >> > > slip a couple of times. I fully agree enforcing this. >> > >> > Well, enforcing it strictly never really worked all that well in >> > practice, since you don't necessarily want to have a complex driver >> > implementation while hashing out the API, and the API fundamentally has >> > to come first. >> > >> > So in a sense it comes down to trust, and that people will actually >> > follow up with implementations. And yeah, plans can change and you end >> > up not really supporting everything that was defined ... that's life, I >> > guess. >> > >> > But the mode here seems to be that there's not even any _intent_ to do >> > that? >> > >> > I guess we could hash out the API, review the patches, and then _not_ >> > apply them until a driver is ready? So the first round of reviews would >> > still come with API only, but once that settles we don't actually merge >> > it immediately, unlike normally where we merge a patch we've reviewed? >> > And then if whoever did it lost interest, we already have a reviewed >> > version for anyone else who might need it? >> >> Sounds like a plan. Maybe they can get a separate state in patchwork and >> let them sit there for grabs. > > I guess I can leave them open as 'under review' or something? Not sure > we can add other states. I belong to the church of 'Clean Inbox' so I use 'Deferred' state for stuff I can't work on right now. Though I know a lot of people don't like it because deferred patches are not shown in the default patchwok view. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
