George T Kramer

Today, this prints the following messages: ``` $ mixer build update --offline --config /home/clrbuilder/projects/clr-release-tools/chroots/builder.conf --min-version 29750 --format 28 --no-publish --no-signing --native Warning: Using PREVIOUS_MIX_VERSION default value ``` It would be...

Would be obsoleted with a CLI design similar to #627

Similarly, I think it would negate the need for a separate tool for upstream vs downstream mixing since the differences are in how sources are defined. There is a good...

While the use cases where we'd actually need more than two sources for bundles and repos are probably limited, I think what we gain here is a more flexible interface...

There is quite a bit of behavior built into mixer that checks whether it's being used correctly and sensibly. There's different checks for each of its commands. This is useful...

A `mixer validate` command may be confusing with `mixer build validate`. It might make sense to have `mixer validate workspace` and `mixer validate update` commands so validation operations are tied...

Ideally, the `mixer validate` commands are optional since they are not a required part of the process. They would only give assurance to users that things are looking sensible for...

The `mixer validate` commands would be run either just before or after the `mixer build` commands. Then, mixer does not attempt to perform validation as users are setting up their...

@otaviobp for thoughts from swupd @mdhorn for thoughts from clr-installer @reaganlo for thoughts from mixer

This finishes the last bit of implementing custom signing