-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: September 5, 2018 1:54 PM To: Saul Wold <sgw@linux.intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions
On Wed, Sep 5, 2018 at 12:16 PM, Saul Wold <sgw@linux.intel.com> wrote:
I agree with this, similar to what git and some other tools do also, I like the examples you provided below.
Sooooo..... git should mostly not be used as an example UI for most purposes, it is a bit of a mess :)
git remote add ... (ok, but...) git branch -m ... (not branch move? branch is sometimes an object and sometimes a verb depending on the options!!)
I think it would be better if was more like
stxb build iso stxb build all
I know this is different than the mirror actions above, but the "all" does not make sense to me in this usage.
This is the what-comes-first question, the object or the action? VMS is still leaking from my brain in that I also prefer the action (verb) to be first. OSC reversed itself 5 years ago because of the bash-completion issue, we use cliff to implement the command parser (built on top of argparse) and doing verb- first and bash completion turned out to be a mess. That is an implementation driving design, which is not always great, but was acceptable to the team at the time.
Which ever order is settled on, PLEASE make all commands the same. The UX studies we did with OSC always showed this consistency to be very important to both new and experienced users.
+1 on consistency :) I think we need discussion around what we're really trying to accomplish. Going back to Cesar's initial proposal, the problem he wanted solved was that his team felt that there were too many commands required to produce an ISO after you've downloaded the mirrors (generate-cgcs-centos-repo.sh, build-pkgs, build-iso) and wanted to wrap those in a single command. Please correct me if I've misstated the problem, Cesar. Furthermore, I think you were looking for a command which did the steps that a developer would execute and not do the steps that a developer would not (downloading the mirror, is intended to be done at a per-site level, not a per-developer level, and would not necessarily be included in the single-command). Finally, the command was intended to be expandable and adaptable in the future (again, please correct me if I've misstated anything). Other than the "meet all conceivable future needs" requirement, I don't see much that couldn't be done with something like a Makefile: make mirror make environment make build make iso especially if you have the "iso" target depend on the "build" target which depends on the "environment" target, etc, then the whole process boils down to one "make iso" command for a developer (2 commands if they have to download the mirror themselves). Note that I'm not proposing "make" as a solution, I understand the concern that make wouldn't meet our needs in the future, and make can be less than pretty. I'm more engaging in the thought exercise of "what problem are we really trying to solve and has anyone solved it in the past" If we're wrapping or re-writing the build commands to make it simpler/easier for a developer, we should define proper use cases and make sure we're solving the right problems. To go off on a tangent, I find the illegible output of the build commands to be much more a stumbling block than the fact that I have to execute 3 commands rather than 1 to produce a build.
dt
--
Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss