Closing down the wireless trees for a summer break?

Closing down the wireless trees for a summer break?

[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.

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

Re: Closing down the wireless trees for a summer break?

[Toke Høiland-Jørgensen]

Kalle Valo <kvalo@kernel.org> 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

Re: Closing down the wireless trees for a summer break?

[Jakub Kicinski]

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.

Re: Closing down the wireless trees for a summer break?

[Johannes Berg]

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

Re: Closing down the wireless trees for a summer break?

[Jakub Kicinski]

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 :)

Re: Closing down the wireless trees for a summer break?

[Greg KH]

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

Re: Closing down the wireless trees for a summer break?

[Johannes Berg]

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.

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.


> > 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

Re: Closing down the wireless trees for a summer break?

[Toke Høiland-Jørgensen]

Johannes Berg <johannes@sipsolutions.net> 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

Re: Closing down the wireless trees for a summer break?

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> 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/20230614075502.11765-1-johannes@sipsolutions.net/
https://patchwork.kernel.org/project/linux-wireless/patch/20230612130256.4572-5-linyunsheng@huawei.com/

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

Re: Closing down the wireless trees for a summer break?

[Jakub Kicinski]

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.

Re: Closing down the wireless trees for a summer break?

[Toke Høiland-Jørgensen]

Jakub Kicinski <kuba@kernel.org> 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

Re: Closing down the wireless trees for a summer break?

[Kalle Valo]

Jakub Kicinski <kuba@kernel.org> 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

Re: Closing down the wireless trees for a summer break?

[Andy Shevchenko]

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?

Also see
https://www.reddit.com/r/linux/comments/s09as7/looks_like_the_domain_registration_recently/
http://deb.tandrin.de/phb-crystal-ball.htm



-- 
With Best Regards,
Andy Shevchenko

Re: Closing down the wireless trees for a summer break?

[Kalle Valo]

Andy Shevchenko <andriy.shevchenko@intel.com> 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:

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,

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: Closing down the wireless trees for a summer break?

[Johannes Berg]

On Thu, 2023-07-13 at 13:30 +0300, Kalle Valo wrote:
> Andy Shevchenko <andriy.shevchenko@intel.com> 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

Re: Closing down the wireless trees for a summer break?

[Andy Shevchenko]

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 <andriy.shevchenko@intel.com> 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

Re: Closing down the wireless trees for a summer break?

[Kalle Valo]

Kalle Valo <kvalo@kernel.org> 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