Here's some bits of the recent Lc0 development status:

1. We've accumulated enough changes (new API, integrating DAG into master, etc) to have the next release soon.

2. As mentioned above, now when you have a PR to update the website, a draft version of the website is available. Hopefully we'll get the site cleaned up, but so far there's no concrete progress.

3. I'm slowly writing the new search. It surely will NOT be the part of the upcoming release. It's mostly on the exploration stage now, with a few quite "experimental"/questionable ideas, which may or may not work, but I have quite high hopes. I'll share something as soon as there's something barely runnable.

4. The overall progress is very slow but steady — it's only borg and myself who are active currently, with very limited time (e.g. I set my alarm for 5:45am to squeeze in 45 minutes of Lc0 before my day job). There are no discussions or large development "behind the scenes".

5. Not sure if posts like this one here in Discord is the best way for status updates. They are community-focused rather than public announcements, so blog posts don't look appropriate. If that would help, I can set up GitHub Project page to share what's coming up.

6. As I mentioned earlier, after the search rewrite, the plan for the next step is training loop redesign. We need to make training/model experiments easier, more accessible (i.e. not having to set up the entire server), and have better use/utilization of the computation resources that we have.

Let me (Borg) take the opportunity to add my (short term) task list.
0. PR reviews and bug fixes. Not a lot to say here, except that the dag code is not considered stable, which is why is is under the name `dag-preview` (will change in a future release). I still have some issues reported that need to be evaluated and addressed, and I expect a lot more as we move towards a release (see point 4).
1. Reduce code duplication between dag and classic: This is mainly for stoppers and search parameters. The stoppers code is nearly identical, but requires access to the `Node` in a very central spot to get some constants for the memory size estimation. Similarly the search parameters have a large common part that can be factored out.
2. Investigate generating sycl binaries for windows. This is probably just a question of figuring out how to get the icx compiler to work with appveyor, but there may be some complications with the mimalloc library.
3. Make the release. For the release I want to update the custom onnxruntime build we use (to disable the telemetry included in the official releases) as the current one is rather old. This may allow us to also offer onnx-trt, but this depends on several factors outside my control so we'll see how it goes. I also want to investigate the option of offering binaries for multiple cuda versions. Finally, the inclusion of dag-preview may necessitate generating more than one release candidates.