Tomas Kral

@feloy added one more acceptance criterion. Experimental flags/commands should not be hidden (not showing up in help, but otherwise working), but completely disabled (they should not exist in "normal" mode...

> 1. What resource odo created > 2. What is the state of these resources > > This could be done via `odo deploy list`. Would it make sense to...

> Listing resources created by `odo deploy` there won't be technically correct, IMO. I don't see it that way. Even the outer loop resources are still part of the devfile...

> You aren't wrong, but `odo deploy` isn't a shorthand for `odo component deploy`. It is not but it should be, `odo deploy` means execute what is in devfile under...

> As I see it devfile = odo component. So every command that odo does is action on top of the component. It doesn't make sense to have `component` subcommand...

Let's NOT do `odo list --deploy`. `odo list` should list both "inner loop" and "outer loop" by default. User should be able to know status of it's components in one...

To show the state we could simply modify the component state. Let's rename `STATE` to `PUSH STATE` and add new `DEPLOY STATE` Deploy state will have similar states as Push...

> I am open to counter view(s) and change my opinion based on a valid argument. support for Go 1.17, which odo currently uses, ended with the 1.19 release. _Each...

if there are issues with upgrading to 1.19 (because it is still too new) we can upgrade to 1.18. But using 1.17 is not ok, as it is no longer...

I started playing with this and it keeps failing on "sync". ``` ✗ Command 'tar xf - -C /projects --no-same-owner' in container failed. ✗ stdout: ✗ stderr: ✗ err: exit...