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.
Thanks.
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.
I confess I read about this feature proposal, and then forgot about it. I concur with Tristan, we should leave this out of scope.
[...]
> 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.
+1.
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.
In other words, it's perfectly ok to implement (and land) the full design incrementally.
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 ?"
To keep things simple I would go for the second option. If you want to apply different options to each workspace, open them individually. Or open groups of them with common options.
Cheers,
-Tristan
Cheers,
Sander
_______________________________________________
BuildStream-list mailing list
BuildStream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list
