Re: [BuildStream] Proposal: Workspace related DX features & design

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Hi all.

First thanks a lot to William and Tom for taking the time to brainstorm
this, and sorry that I've been so tied up that I could not yet
participate, even though this is an important topic to me.

I will make a comment or two on this initial email which I think have
not been discussed yet, and then move on to replying to the end of the
current thread.

On Fri, 2018-08-24 at 13:06 +0100, William Salmon via BuildStream-list wrote:
[...]
>  Once a change has been developed in a workspace it would be 
> desirable to have an easy way to get this information into the respective 
> upstream/vcs (or even just locally for the projects consuming it); we think this 
> may need to expand the workspace API but not change any existing features e.g. 
> `bst workspace patch create` (or a documented patch/quilt workflow) or similar.

This sounds like an interesting proposal but I think will not overlap
with other bst CLI APIs, so let's leave this safely out of scope for
the enhancements we already have to consider here.

[...]
> As we propose to land all the 
> CLI changes to `workspace open` command in one MR, we may need to land the 
> option before the feature is ready. In this case we will have bst issue a "not 
> implemented" error if the --use-cache option was used.

Absolutely not.

The addition of a flag will not be added to the CLI before it's
supporting feature is actually implemented.

If this must be considered as a part of the API proposal, then it is in
design phase and the resulting design decisions must be captured in the
corresponding issue report accordingly, in this case:

  Opening a workspace with a cached build
  https://gitlab.com/BuildStream/buildstream/issues/311

Once this proposal / design is settled, it will be important to update
any relevant issues with the design decisions reached, and ensure that
we have relatively small / consumable tasks which we can roadmap and
land easily enough; try to avoid planning for overly large merge
requests.

Asides from that, the only part I see here that is contentious with
other related features, is the ambiguity which arises from opening
multiple workspaces in a single `bst` command.

However note that if there is a "flag which effects how a workspace is
opened", then there might be more than one flag to consider than just
the `--cache/--no-cache` flag.

So I think that rather than talking about `--cache/--no-cache`
specifically here; we should be asking the question:

  "When opening multiple workspaces, can we specify options for
   each workspace being opened separately ?

   Or must we specify a single set of options which apply to
   every workspace being opened ?"

Cheers,
    -Tristan