Second generation moved away from gVisor:

https://cloud.google.com/blog/products/serverless/cloud-run-...

You can use the real compose (Go) with Podman now. The Python clone is not your only option.

Sometimes it crashes just running regular apt-get upgrade if it has too many packages to update, or takes too long. Switching away from the app can also mean it crashes.

Nice idea, nowhere near ready for anything but playing.

The sub-issues are good, with more relationship types coming (dependencies, not just parent-child). The better search is welcome. However there are some questions for me in relation to the overall semantics of labels, issue types and project fields.

Labels are repo only and multi valued. Issue types are organisation wide and single valued, project fields are the richest, but no multi-valued option, and they end up in a disjointed place in the API (you can't get at them easily when what you have is the issue, you have to go in via the project).

An example of this disjointed feeling it that there are no "issue type"s for a PR. This means that if you want to share metadata between PR and Issues, you have to use labels anyway.

I do wonder if types could have been better implemented as namespaces for labels. This combined with being able to have organisation or repo context label namespaces would have allowed for far more flexibility.

The other thing that vanished from the public roadmap amongst all this was support for better workflows. Currently there's no easy way to create allowed state transitions between metadata state (e.g in a project stop issues being able to skip the QA status).

The attention this area is getting is welcome, and there are many good things in there, but it does feel a bit disjointed. A more unified metadata model would be welcome.

They are in some countries. The sugar tax in the UK quickly led to many places only selling non sugar variants or charging a premium for the sugared versions.