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

[Thomas Coldrick <thomas coldrick codethink co uk>]

Hi all,

I'd really like to see BuildStream 2.0 released sometime soon after using
master for various projects and being wowed by the new CLI and performance
improvements. I'd love to see projects which need to use a stable release
also seeing them!

On 28/01/2020 16:44, Chandan Singh wrote:
> > > 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.
> This is essentially captured in
> https://gitlab.com/BuildStream/buildstream/issues/719.
>
> There has been significant effort in this area, but there's still work to be
> done. Probably the most hairy will be supporting workspaces and interactive
> shells.
There's been some great work from Jürg et al. on this for sure, and I'm
looking forward to using it. Am I right in thinking that due to these
improvements, a stable release of BuildBox is also a blocker for BuildStream
2.0, and if so is there any indication of when such a thing could happen, or
what blockers there are?

> The infrastructure is mostly there, although we can improve how we run plugin
> tests.
>
> The main work left here is to actually do the splitting up of the repos, but
> that should probably happen_after_  the plugin API has been more or less
> stabilized. This is important because we are still working on the plugin API,
> and making breaking changes.

I'm glad we're making headway on the plugin story at last, it'd be great to
start splitting these into the necessary repos so that there's an 
obvious path
for BuildStream projects to make their migration. I believe that the 
specific
domains we're going to split them into is still TBD, perhaps it's time 
to start
thinking about this?

I agree that such things should start after the plugin API is stabilised,
but I cannot find any issues regarding future changes for the plugin API.
Aside from slapping on a guarantee of stability, is there anything left to
be done for this?

> > > 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?
> Other than unplanned changes, this is captured in
> https://gitlab.com/BuildStream/buildstream/issues/1068.

I'm glad this is being tracked! I think it might be worth hunting down
the blockers and labeling them as such, so that it's obvious from looking
at GitLab what needs to be done before a release.

> > 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.
> I can sympathize with the desire to get into next release. But I don't think
> that can be promised at this time. If we finish all the blockers in time, and
> are happy with the state of the API, then sure. But, what will be worse is if we
> make an incomplete release and have to break the API two months into bst 2.0.

Has any discussion been started on what we want to stabilise for public 
API yet? I
agree that rushing and having to break API quickly is a huge problem, and we
should start thinking about what API is guaranteed stable for 2.0. 
Personally, I
don't see any issue in stabilising what is currently public for 2.0, and 
waiting
for later releases to open up more exciting parts.

Thanks,

Tom