Closing down the wireless trees for a summer break?
Subsystems (3)
Me and Johannes are planning to take a longer break from upstream this summer. To keep things simple my suggestion is that we would official close wireless and wireless-next trees from June 23rd to August 14th (approximately).
During that time urgent fixes would need go directly to the net tree. Patches can keep flowing to the wireless list but the the net maintainers will follow the list and they'll just apply them to the net tree directly.
The plan here is that -next patches would have to wait for wireless-next to open. Luckily the merge window for v6.6 most likely opens beginning of September[1] so after our break we would have few weeks to get -next patches ready for v6.6.
And the v6.5 -next patches should be ready by Monday June 19th so that we have enough time to get them into the tree before we close the trees.
What do people think, would this work? This is the first time we are doing this so we would like to hear any comments about this, both negative and positive. You can also reply to me and Johannes privately, if that's easier.
Kalle
[1] https://phb-crystal-ball.sipsolutions.net/
Signature · 3 lines
https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Quoted 15 lines · Kalle Valo
Me and Johannes are planning to take a longer break from upstream this summer. To keep things simple my suggestion is that we would official close wireless and wireless-next trees from June 23rd to August 14th (approximately).
During that time urgent fixes would need go directly to the net tree. Patches can keep flowing to the wireless list but the the net maintainers will follow the list and they'll just apply them to the net tree directly.
The plan here is that -next patches would have to wait for wireless-next to open. Luckily the merge window for v6.6 most likely opens beginning of September[1] so after our break we would have few weeks to get -next patches ready for v6.6.
Quoted 7 lines
And the v6.5 -next patches should be ready by Monday June 19th so that we have enough time to get them into the tree before we close the trees.
What do people think, would this work? This is the first time we are doing this so we would like to hear any comments about this, both negative and positive. You can also reply to me and Johannes privately, if that's easier.
I think this sounds reasonable, and I applaud the effort to take some time off during the summer :)
One question that comes to mind is how would this work for patchwork? Would we keep using the wireless patchwork instance for the patches going to -net in that period, or will there be some other process for this? I realise the setup we have for ath9k is a bit special in this regard with the ack-on-list+delegation, so I'm obviously mostly interested in what to do about that... :)
-Toke
Jakub Kicinski
maintainerQuoted 9 lines · On Tue, 13 Jun 2023 20:14:40 +0200 Toke Høiland-Jørgensen wrote:
I think this sounds reasonable, and I applaud the effort to take some time off during the summer :)
One question that comes to mind is how would this work for patchwork? Would we keep using the wireless patchwork instance for the patches going to -net in that period, or will there be some other process for this? I realise the setup we have for ath9k is a bit special in this regard with the ack-on-list+delegation, so I'm obviously mostly interested in what to do about that... :)
Whatever's easiest :) It's probably a good idea for Kalle to write down all the local rules and customs and share those with us.
Quoted 11 lines · Jakub Kicinski
Quoted 9 lines · On Tue, 13 Jun 2023 20:14:40 +0200 Toke Høiland-Jørgensen wrote:
I think this sounds reasonable, and I applaud the effort to take some time off during the summer :)
One question that comes to mind is how would this work for patchwork? Would we keep using the wireless patchwork instance for the patches going to -net in that period, or will there be some other process for this? I realise the setup we have for ath9k is a bit special in this regard with the ack-on-list+delegation, so I'm obviously mostly interested in what to do about that... :)
Quoted 3 lines
Whatever's easiest :) It's probably a good idea for Kalle to write down all the local rules and customs and share those with us.
While that's probably a good idea regardless, I'd think that patchwork doesn't really matter that much - we'll have some catching up to do anyway after the vacations, so looking through patchwork etc. would be perfectly acceptable. Worst case we'd notice when a patch doesn't apply, right? :)
Wrt. ath9k patches I guess "delegate in patchwork" won't work anymore, but "resend to netdev" or something perhaps?
johannes
Jakub Kicinski
maintainerQuoted 12 lines · On Tue, 13 Jun 2023 22:00:35 +0200 Johannes Berg wrote:
Quoted 11 lines · Jakub Kicinski
Quoted 9 lines · On Tue, 13 Jun 2023 20:14:40 +0200 Toke Høiland-Jørgensen wrote:
I think this sounds reasonable, and I applaud the effort to take some time off during the summer :)
One question that comes to mind is how would this work for patchwork? Would we keep using the wireless patchwork instance for the patches going to -net in that period, or will there be some other process for this? I realise the setup we have for ath9k is a bit special in this regard with the ack-on-list+delegation, so I'm obviously mostly interested in what to do about that... :)
Quoted 8 lines
Quoted 2 lines
Whatever's easiest :) It's probably a good idea for Kalle to write down all the local rules and customs and share those with us.
While that's probably a good idea regardless, I'd think that patchwork doesn't really matter that much - we'll have some catching up to do anyway after the vacations, so looking through patchwork etc. would be perfectly acceptable. Worst case we'd notice when a patch doesn't apply, right? :)
Right, I meant it more in terms of patch flow. Is looking at which drivers have a tree specified in MAINTAINERS enough to know what should be applied directly?
Quoted 2 lines
Wrt. ath9k patches I guess "delegate in patchwork" won't work anymore, but "resend to netdev" or something perhaps?
We can watch PW state and apply from linux-wireless, I reckon. That said I don't know how you use delegation :)
Quoted 22 lines · Jakub Kicinski
Quoted 12 lines · On Tue, 13 Jun 2023 22:00:35 +0200 Johannes Berg wrote:
Quoted 11 lines · Jakub Kicinski
Quoted 9 lines · On Tue, 13 Jun 2023 20:14:40 +0200 Toke Høiland-Jørgensen wrote:
I think this sounds reasonable, and I applaud the effort to take some time off during the summer :)
One question that comes to mind is how would this work for patchwork? Would we keep using the wireless patchwork instance for the patches going to -net in that period, or will there be some other process for this? I realise the setup we have for ath9k is a bit special in this regard with the ack-on-list+delegation, so I'm obviously mostly interested in what to do about that... :)
Quoted 8 lines
Quoted 2 lines
Whatever's easiest :) It's probably a good idea for Kalle to write down all the local rules and customs and share those with us.
While that's probably a good idea regardless, I'd think that patchwork doesn't really matter that much - we'll have some catching up to do anyway after the vacations, so looking through patchwork etc. would be perfectly acceptable. Worst case we'd notice when a patch doesn't apply, right? :)
Quoted 3 lines
Right, I meant it more in terms of patch flow. Is looking at which drivers have a tree specified in
MAINTAINERSenough to know what should be applied directly?
Oh, right. Not really sure how well that all is reflected in MAINTAINERS.
So Gregory usually handles patches for iwlwifi, but he'll _also_ be on vacation around a similar time frame.
Toke usually reviews patches for ath9k but then asks Kalle (via assigning in patchwork) to apply them.
Felix usually picks up patches for mediatek drivers (unless specifically asking Kalle for individual ones) and then sends a pull request.
For the stack (all the bits we have under net/) that's just on me, normally.
I think that's it? But I guess Kalle will have more comments.
Quoted 5 lines
Quoted 2 lines
Wrt. ath9k patches I guess "delegate in patchwork" won't work anymore, but "resend to netdev" or something perhaps?
We can watch PW state and apply from linux-wireless, I reckon. That said I don't know how you use delegation :)
We have auto-delegation set up for this, except iwlwifi is on me right now for the upstream, and I just delegate other incoming patches to Gregory.
johannes
Quoted 2 lines · Johannes Berg
Toke usually reviews patches for ath9k but then asks Kalle (via assigning in patchwork) to apply them.
As for this bit I suppose we can either agree that I do the patchwork delegation to someone else during the break (who?), or that y'all on the net maintainer side just apply any patches that I ACK on the list without further action on my part. No strong preference, whatever works best for you, Jakub :)
-Toke
Quoted 24 lines · Johannes Berg
Quoted 22 lines · Jakub Kicinski
Quoted 20 lines · On Tue, 13 Jun 2023 22:00:35 +0200 Johannes Berg wrote:
Quoted 11 lines · Jakub Kicinski
Quoted 9 lines · On Tue, 13 Jun 2023 20:14:40 +0200 Toke Høiland-Jørgensen wrote:
I think this sounds reasonable, and I applaud the effort to take some time off during the summer :)
One question that comes to mind is how would this work for patchwork? Would we keep using the wireless patchwork instance for the patches going to -net in that period, or will there be some other process for this? I realise the setup we have for ath9k is a bit special in this regard with the ack-on-list+delegation, so I'm obviously mostly interested in what to do about that... :)
Quoted 2 lines
Whatever's easiest :) It's probably a good idea for Kalle to write down all the local rules and customs and share those with us.
While that's probably a good idea regardless, I'd think that patchwork doesn't really matter that much - we'll have some catching up to do anyway after the vacations, so looking through patchwork etc. would be perfectly acceptable. Worst case we'd notice when a patch doesn't apply, right? :)
Quoted 6 lines
Quoted 3 lines
Right, I meant it more in terms of patch flow. Is looking at which drivers have a tree specified in
MAINTAINERSenough to know what should be applied directly?Oh, right. Not really sure how well that all is reflected in
MAINTAINERS.
Now that I sent some updates, the separate driver specific trees should be pretty well documented in MAINTAINERS:
https://patchwork.kernel.org/project/linux-wireless/list/?series=757173
But do let me know if I missed something.
Quoted 6 lines
So Gregory usually handles patches for iwlwifi, but he'll _also_ be on vacation around a similar time frame.
Toke usually reviews patches for ath9k but then asks Kalle (via assigning in patchwork) to apply them.
Quoted 7 lines
Felix usually picks up patches for mediatek drivers (unless specifically asking Kalle for individual ones) and then sends a pull request.
For the stack (all the bits we have under
net/) that's just on me, normally.I think that's it? But I guess Kalle will have more comments.
And for drivers/net/wireless/ath/ I have my ath.git tree for which I take all patches for drivers under that directory. (BTW I might be updating my ath.git tree some time during summer, but no promises. I will be mostly offline and not even checking email.)
But do note that above is _only_ for -next patches. For patches going to -rc releases we apply the patches directly to wireless, no other trees are involved. My proposal was that net maintainers would take only fixes for -rc releases, my guess from history is that it would be maximum of 10-15 patches. And once me and Johannes are back we would sort out -next patches before the merge window. But of course you guys can do whatever you think is best :)
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
Wrt. ath9k patches I guess "delegate in patchwork" won't work anymore, but "resend to netdev" or something perhaps?
We can watch PW state and apply from linux-wireless, I reckon. That said I don't know how you use delegation :)
We have auto-delegation set up for this, except iwlwifi is on me right now for the upstream, and I just delegate other incoming patches to Gregory.
Auto-delegation is awesome, it helps our workflow quite a lot. Though it's not perfect and some of the patches will not get delegated automatically. So I periodically check this link if there are patches needing for manual delegation:
As an example, right now I see one pull request and one patch:
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
It's a minor nuisance so I haven't bothered to even report it to patchwork project.
Signature · 3 lines
https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Jakub Kicinski
maintainerQuoted 7 lines · On Wed, 14 Jun 2023 18:07:43 +0300 Kalle Valo wrote:
But do note that above is _only_ for -next patches. For patches going to -rc releases we apply the patches directly to wireless, no other trees are involved. My proposal was that net maintainers would take only fixes for -rc releases, my guess from history is that it would be maximum of 10-15 patches. And once me and Johannes are back we would sort out -next patches before the merge window. But of course you guys can do whatever you think is best :)
Ah, good note, I would have guessed that fixes go via special trees, too. In that case it should indeed be easy. We'll just look out for maintainer acks on the list and ping people if in doubt.
Quoted 9 lines · Jakub Kicinski
Quoted 7 lines · On Wed, 14 Jun 2023 18:07:43 +0300 Kalle Valo wrote:
But do note that above is _only_ for -next patches. For patches going to -rc releases we apply the patches directly to wireless, no other trees are involved. My proposal was that net maintainers would take only fixes for -rc releases, my guess from history is that it would be maximum of 10-15 patches. And once me and Johannes are back we would sort out -next patches before the merge window. But of course you guys can do whatever you think is best :)
Quoted 3 lines
Ah, good note, I would have guessed that fixes go via special trees, too. In that case it should indeed be easy. We'll just look out for maintainer acks on the list and ping people if in doubt.
SGTM! :)
-Toke
Quoted 9 lines · Jakub Kicinski
Quoted 7 lines · On Wed, 14 Jun 2023 18:07:43 +0300 Kalle Valo wrote:
But do note that above is _only_ for -next patches. For patches going to -rc releases we apply the patches directly to wireless, no other trees are involved. My proposal was that net maintainers would take only fixes for -rc releases, my guess from history is that it would be maximum of 10-15 patches. And once me and Johannes are back we would sort out -next patches before the merge window. But of course you guys can do whatever you think is best :)
Quoted 3 lines
Ah, good note, I would have guessed that fixes go via special trees, too. In that case it should indeed be easy. We'll just look out for maintainer acks on the list and ping people if in doubt.
Sounds good. And do note that not all drivers have active maintainers, so you might have to take some patches without acks.
Signature · 3 lines
https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Quoted 15 lines · Kalle Valo
Me and Johannes are planning to take a longer break from upstream this summer. To keep things simple my suggestion is that we would official close wireless and wireless-next trees from June 23rd to August 14th (approximately).
During that time urgent fixes would need go directly to the net tree. Patches can keep flowing to the wireless list but the the net maintainers will follow the list and they'll just apply them to the net tree directly.
The plan here is that -next patches would have to wait for wireless-next to open. Luckily the merge window for v6.6 most likely opens beginning of September[1] so after our break we would have few weeks to get -next patches ready for v6.6.
Quoted 7 lines
And the v6.5 -next patches should be ready by Monday June 19th so that we have enough time to get them into the tree before we close the trees.
What do people think, would this work? This is the first time we are doing this so we would like to hear any comments about this, both negative and positive. You can also reply to me and Johannes privately, if that's easier.
Sounds reasonable to me, have a nice vacation!
greg k-h
On Tue, Jun 13, 2023 at 05:22:47PM +0300, Kalle Valo wrote:
...
Quoted 1 line
How could one use the shut down site?
Also see
https://www.reddit.com/r/linux/comments/s09as7/looks_like_the_domain_registration_recently/
http://deb.tandrin.de/phb-crystal-ball.htm
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 7 lines · Andy Shevchenko
On Tue, Jun 13, 2023 at 05:22:47PM +0300, Kalle Valo wrote:
...
Quoted 1 line
How could one use the shut down site?
What do you mean? At least from Finland it Works for me:
xps9310:~$ lynx -dump https://phb-crystal-ball.sipsolutions.net/ | head Predictions
Based on the last 74 kernel releases,with an average development time
of 67 days, 20:19:25.986301,and merge window time of 13 days,
17:02:03.364865,
* the v6.5 kernel predictions: merge window closes on
Sunday,
2023-07-09 and release on Sunday, 2023-09-03
* the v6.6 kernel predictions: merge window closes on
Sunday,
2023-09-17 and release on Sunday, 2023-11-12
* the v6.7 kernel predictions: merge window closes on
Sunday,Signature · 3 lines
https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Quoted 11 lines · Kalle Valo
Quoted 7 lines · Andy Shevchenko
On Tue, Jun 13, 2023 at 05:22:47PM +0300, Kalle Valo wrote:
...
Quoted 1 line
How could one use the shut down site?
What do you mean? At least from Finland it Works for me:
That did in fact not work yesterday for some time as I was doing some maintenance :)
johannes
Quoted 3 lines · Johannes Berg
Quoted 2 lines · Kalle Valo
Quoted 1 line · Andy Shevchenko
On Tue, Jun 13, 2023 at 05:22:47PM +0300, Kalle Valo wrote:
...
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
How could one use the shut down site?
What do you mean? At least from Finland it Works for me:
That did in fact not work yesterday for some time as I was doing some maintenance :)
Good to know!
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 9 lines · Kalle Valo
Me and Johannes are planning to take a longer break from upstream this summer. To keep things simple my suggestion is that we would official close wireless and wireless-next trees from June 23rd to August 14th (approximately).
During that time urgent fixes would need go directly to the net tree. Patches can keep flowing to the wireless list but the the net maintainers will follow the list and they'll just apply them to the net tree directly.
A change of plans, I'm actually back already now and have opened both wireless and wireless-next trees. I will go back offline at some point but hopefully Johannes will be back by then.
Signature · 3 lines
https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches