Re: [BuildStream] BuildStream 2.0 - must have's

[William Salmon <will salmon codethink co uk>]

On 15/10/2019 18:23, Chandan Singh wrote:
> Hi all,
>
> In one of the previous BuildStream Gathering event, it was decided that
> BuildStream 2.0 will be "ready when it's ready". I don't think much has changed
> there but I wanted to capture the issues that must be resolved before 2.0 so
> that we can plan for it accordingly.
>
> The aim of this thread is not to decide everything here and now, but rather to
> capture all decisions that need to be made before we can make a stable release.


Not worrying about releases has seen bst2's development really take off, 
its amazing to see how far it has come and I am really excited about it 
stabilizing to the point were it is ready for use with more projects and 
being able to release bst2!


> Sandboxing
> ----------


I like that we want to move as much sand box code out of core as 
possible and moving to BuildBox as fast as possible should be high up on 
our priorities but dose this need further changes to public API or are 
there some other blockers that means we need to wait on this for bst2? 
Can further work be in bst2.0.x or bst2.x? I imaging there may well be a 
good reason to wait for this, but I know a lot of work has already been 
done.


> Plugins
> -------


Plugins are really important so its not surprising that our community 
has spent a lot of time thinking and talking about plugins (not lease 
myself) because we all really care about them, as getting them right is 
key to bst's future success.

Apart from actually moving them out and giving them a bit of a shake up, 
are we blocked on actually getting on and doing this? We have put in 
place a lot of infra around them that I believe is now working well enough?

An area of discussion that we often stumble over is plugin distribution, 
once all the plugins live out side of the core then there is a little 
more work required to build a hello world project.

Many bst projects already require additional plugin installation and 
those wishing to provide packages for bst may well chose to bundle up 
some of the once "core" plugins in to the base package so i think we 
still have some good options.

Dose the plugin distribution story need to block bst2 any further? I 
presume if we need to have a more integrated plugin fetching system it 
would be Additional API rather than braking and so fit in bst2.x?


> CLI
> ---


We have made a lot of CLI changes since bst1.2 but looking at [1] I see 
that of the outstanding issues there are quite a few issues that have 
ended up being controversial. I wonder which of our outstanding issues 
we wish to block bst2 on?


> Artifact Server
> ---------------
[...]
> Stability guarantees
> --------------------
[...]
> Performance
> -----------
[...]


I have not been following the Artifact/performance work, other than to 
note that the core performance has made some leaps and bounds since 1.2, 
it has been great to see Ben et al. working very hard and delivering 
remarkable improvements, Do these have any other outstanding work that 
would block bst2?

I appreciate that Stability and Performance never go away and will 
require constant attention as new patches land.

That said the big improvements that have been made are part of the 
reason I am keen to move to bst2. Especially as I would like to start 
using the new sandboxes so I can test and help as they will make a huge 
impact to run times of the projects that I work on, as well as the 
progress that has already been made to the core's performance.


> ---
>
> That's the main areas that I can think of. If you can think of anything else,
> please reply back to this message.


I think we have made a lot of progress on the above, I suspect we are 
quite close.

Some things that I think we are also quite close to not needing to block 
on but that I would like your feed back on is

Remote execution
----------------

I think we are pretty much there on this (so far as it not blocking 
bst2) but I wonder if there are any API changes that we should do before 
bst2.

---

I don't want to put too much time presser on ourselves as I am sure lots 
of things will come out of the wood work as more projects jump to 
bst2/preview. However it has been noted that Ubuntu's next LTS release 
is this spring [2] so if we got a wriggle on then we might be able to 
get bst2 released in time!

I think getting in to 20.04 would be a nice thing to aim for as it would 
help bst2 adoption but I don't think it is anyway near as important as 
getting bst2 right.


> Once we have a list that people agree on, my aim is to convert these items into
> GitLab issues and tag them with some tag indicating that they are needed for
> BuildStream 2. That way anyone wanting to know what's blocking BuildStream 2.0
> release will be able to do so by looking at all issues with that tag.
>
> Thanks,
> Chandan
> _______________________________________________
> buildstream-list mailing list
> buildstream-list gnome org
> https://mail.gnome.org/mailman/listinfo/buildstream-list

[1] https://gitlab.com/BuildStream/buildstream/issues/1068
[2] https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule