Build summary UX

[Aleksey Shipilev]

Hi Erik,

Thanks for the explanations, comments below:

On 08/21/2014 07:39 PM, Erik Joelsson wrote:
> As I have tried to explain a couple of times now: The jdk8 build built
> each repository in sequence (much like the jdk7 build did). Because of
> this it made sense to add messages about which repository was being
> built and measure the time each took. 

I'm glad to see I am not lonely in questioning this? :)


> The new jdk9 build is not repository oriented, but instead builds
> modules. To increase concurrency, I dropped the sequential, non
> parallel, execution model at the top level so there are a larger
> number of build targets being built at the same time, based on finer
> grained dependencies. What I'm trying to say here is that those
> Starting/Finished messages simply do not exist anymore.

I think this conflates two separate concerns: a) running sequential vs.
parallel; and b) printing what build actually does, even if it figured
it does not need to do anything.

We can even scratch the (a) with JOBS=1. In this case, the build is just
silent about what it does, which is alarming at least for me. See e.g.
how Make prints "Nothing to do" messages. See e.g. how Maven treats
parallel builds: no matter what is the parallelism you ask for, it will
print the build log from each of those parallel-running modules, and
that output, while interleaved, still be the same output you got in
purely sequential builds, which is helpful to gain the trust into the
build. And yes, it also faces dependencies.


> I can understand people wanting more details on what took how much time
> to build, but the timings need to make sense to be useful. If target A
> starts executing, and then the last recipe of that target gets to wait
> while all of target B gets executed, then the time for target A will
> look much longer than it actually was. Perhaps this information would
> still be useful, I doubt it, but could perhaps be swayed by good
> arguments. We would also need to figure out a proper granularity for
> grouping timings, and if it should be grouped by modules or by tasks.

It was my mistake for not being clear about my UX concerns, so this
winded down to timings. Timings are not of my interest, but what modules
the build had considered to build, and what was the result of that
consideration, is important to me.


> I think that verbosity at the default warn level is correct in not
> printing more than it currently does. If something was recompiled, you
> would see messages about it. I can't help but wonder why you need more
> text to say "nothing happened"? This sounds like an issue with not
> trusting the build (which I can identify with, it's new so is likely to
> be buggy). 

Case in point: way too frequently I was changing something in IDE, then
shooting the build from CLI, and then realizing than nothing is rebuilt
in Hotspot, because I was editing the wrong workspace!

You can argue that completely silent build output is the marker of
nothing happened, but given my general mistrust in computers and
especially Make/*sh scripts, I would rather see the explicit "Finished
hotspot in 00:00:01" / "Nothing to do in hotspot" message.

In Unix world, silence seems to indicate the operation completed
successfully. Which means, if I observe the silent output, I have to
wonder if this thing is telling me my code changes are OK, and there is
nothing to worry about; or the build just haven't considered them at
all, which is something I need to worry very much about, and have an
early warning about. Failing to visually distinguish these two cases
*is* an UX gone bad.

See again how Maven handles the multi-module builds: it would print the
order in which the modules are built, and it will print the summary
table of what modules were actually built in the end. Do not
underestimate how useful that output is to understand what just happened
after I requested the build, this saved me more than once.


> When setting LOG=info, I agree that there should be more
> status messages about which targets were actually considered. The step
> up to LOG=debug prints far too much to be useful in that regard. Again,
> we need to think about the granularity of the targets we would want to
> print info about here, and if it should be module or task oriented.

This. I argue that printing the start/finish messages on the basic LOG
level is a good thing for otherwise oblivious users.

Thanks,
-Aleksey.