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/
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Kalle Valo <[email protected]> writes:
> 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.
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
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.
On Tue, 2023-06-13 at 11:28 -0700, Jakub Kicinski wrote:
> 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.
>
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
On Tue, 13 Jun 2023 22:00:35 +0200 Johannes Berg wrote:
> On Tue, 2023-06-13 at 11:28 -0700, Jakub Kicinski wrote:
> > 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.
>
> 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?
> 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 :)
On Tue, Jun 13, 2023 at 05:22:47PM +0300, Kalle Valo wrote:
> 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.
Sounds reasonable to me, have a nice vacation!
greg k-h
Johannes Berg <[email protected]> writes:
> 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
Johannes Berg <[email protected]> writes:
> On Tue, 2023-06-13 at 19:51 -0700, Jakub Kicinski wrote:
>
>> On Tue, 13 Jun 2023 22:00:35 +0200 Johannes Berg wrote:
>> > On Tue, 2023-06-13 at 11:28 -0700, Jakub Kicinski wrote:
>> > > 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.
>> >
>> > 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?
>
> 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.
> 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.
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 :)
>> > 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:
https://patchwork.kernel.org/project/linux-wireless/list/?series=&submitter=&state=&q=&archive=&delegate=Nobody
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.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
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.
Jakub Kicinski <[email protected]> writes:
> 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.
SGTM! :)
-Toke
Jakub Kicinski <[email protected]> writes:
> 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.
Sounds good. And do note that not all drivers have active maintainers,
so you might have to take some patches without acks.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On Thu, 2023-07-13 at 13:30 +0300, Kalle Valo wrote:
> Andy Shevchenko <[email protected]> writes:
>
> > On Tue, Jun 13, 2023 at 05:22:47PM +0300, Kalle Valo wrote:
> >
> > ...
> >
> > > [1] https://phb-crystal-ball.sipsolutions.net/
> >
> > 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
On Thu, Jul 13, 2023 at 01:05:45PM +0200, Johannes Berg wrote:
> On Thu, 2023-07-13 at 13:30 +0300, Kalle Valo wrote:
> > Andy Shevchenko <[email protected]> writes:
> > > On Tue, Jun 13, 2023 at 05:22:47PM +0300, Kalle Valo wrote:
...
> > > > [1] https://phb-crystal-ball.sipsolutions.net/
> > >
> > > 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!
--
With Best Regards,
Andy Shevchenko
Kalle Valo <[email protected]> writes:
> 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.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches