Re: [BuildStream] Proposal: Decouple source tracking and building

[Sander Striker <s striker striker nl>]

Hi,

TL;DR it appears we have reasonable consensus to move forward with the proposal to decouple source tracking and building.

On Mon, Oct 21, 2019 at 11:16 AM Tristan Van Berkom <tristan vanberkom codethink co uk> wrote:

Hi Jürg,

> On Oct 21, 2019, at 5:01 PM, Jürg Billeter <j bitron ch> wrote:
>
[...]
> I don't know whether `bst build --track` is or isn't worth it. However,
> I think it's a valid discussion.

I think that the particular use case that was highlighted for the inclusion of the feature initially, is an interesting one.  We can probably come up with a number of approaches that address the use case performantly without tracking and building being done in the same run.  Especially given the use case wants to start building as soon as previous build has completed.

 

> And yes, we're working towards the removal of `_update_state()`. This
> should help reduce the complexity involved in the combined track+build
> pipeline. However, the track+build pipeline support will not suddenly
> become completely trivial.

So yes, of course trade offs have to be made sometimes, and also refractors should happen continuously.

I’ll try to be clearer (have been replying from smart phone over the day):

* I do think that in the current confusing form of state handling, removing this feature is desirable, even at the cost of losing a luxury feature (it’s not a base feature, but I think BuildStream is a luxury car, not just any vehicle or build script).

Right, I think it's useful to think about it this way (not necessarily in terms of cars, but I like the distinction of base features).  Thanks for explicitly stating that "removing this feature is desirable" given the current context.

* I do not believe that the complexity of how state handling is expressed in the codebase is justified. Maybe I’m wrong about this (hence why I ask in my last reply if my thinking is unreasonable), but I have a very hard time believing that we cannot come up with better separation of concerns in scheduling and state handling.

[...]

 

I would much rather be having a conversation about how we can make the codepaths manageable, if they were more manageable already, I doubt we’d be having this conversation at all (we’d be happily improving performance and adding more luxurious features).

True.  I think that the desire is to simplify enough to get to this point again.

 

Cheers,
    -Tristan

Cheers,

Sander

 

> Cheers,
> Jürg