Re: [BuildStream] Responsive, but not overly verbose UX - not-in-scheduler

[Jonathan Maw <jonathan maw codethink co uk>]

Hi,

I've picked up this task and am looking into ways to solve this problem 
(created https://gitlab.com/BuildStream/buildstream/issues/1029, which 
has a summary of my understanding of the problem).

I have also created a Merge Request with a very basic implementation of 
progress reporting as I envision it at the moment 
(https://gitlab.com/BuildStream/buildstream/merge_requests/1358)

I think the implementation will probably diverge from the proposed 
implementation described in 
https://mail.gnome.org/archives/buildstream-list/2019-April/msg00054.html, 
specifically in regards to how it's presented to the user, as there is 
currenlty ongoing work to move the UI into a separate process 
(https://gitlab.com/BuildStream/buildstream/issues/1036), so my primary 
concern at the moment is to create a consistent and useful interface, 
with a rough implementation in the existing UI that can be updated to 
use the UI in a separate process later.

So far, my task breakdown is:
* Report progress when loading elements (read file to make a 
MetaElement)
  - This has been accomplished in the MR, but the calculation for the 
total number of elements isn't very helpful.
  - There are some ways to make this total more useful (create a set of 
loaded elements and compare it to a set of elements to be loaded), but 
I'm not sure if they're performant enough.
* Report progress when resolving elements (convert MetaElements into 
Elements)
  - This has been accomplished in the MR.
* Report progress when resolving cached state
  - This is where I'll be focussing on next
* Emit status messages when fetching a junction
  - This won't be represented with a progress indicator, but fetching 
junctions is another case of not-readily-apparent slowdowns when 
building.
* Define an API for reporting status messages
  - Currently this is defined by a Context.progress_activity() method 
and a Context.report_progress() method, though it's very rough and I'd 
appreciate feedback.

Once this is in a good mergeable state, my next step will be to define 
an API for plugins to report their progress, and implement progress 
messages in the git source, since that is another point where we spend a 
long time sitting and waiting with no feedback.

Please let me know if you have any suggestions.

Thanks,

Jonathan

--
Jonathan Maw, Software Engineer, Codethink Ltd.
Codethink privacy policy: https://www.codethink.co.uk/privacy.html