I think that's going too far. The VNC and VNC_Vncconnect cases
are
very
different codepaths.
I think it'd be okay to merge VNC and VNC_Password and just require
the
testing to include use of a password.
OK, at least merging these two seems like a no-brainer to me. I'll leave the password
optional, because that way both options get tested eventually.
But Vncconnect should remain
separate. We could consider dropping it from being a blocking test,
though. I'm not sure we actually need to block release on the vnc
connect functionality, though there may be some reason to. Is anyone
aware of the use cases for the vncconnect functionality and how
critical
they are?
I think the main use case is if you want to install a machine behind a firewall, and you
have a public IP. Whether that is critical enough to block the release or not, I do not
know.
Anyone else has an opinion on that?