Re: [BuildStream] [Proposal] 1.4 release (and potential further 1.x releases)

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

Hi Sander,

On Mon, 2019-05-27 at 13:18 +0200, Sander Striker wrote:
> Hi Tristan,
>
> > On Mon, May 27, 2019 at 11:48 AM Tristan Van Berkom via buildstream-list <buildstream-list gnome org> 
> > wrote:
> [...]
> > As discussed in the last team meeting:
> >
> >     https://meetbot.gnome.org/buildstream-meetings/2019/buildstream-meetings.2019-05-14-14.00.log.html
>
> Clarification sidenote: these meetings should not be taken as consensus or the opinion of all actively 
> working on BuildStream.

I tried to choose my words carefully here indeed :)

That said, it should be a good sample, and we are bringing it to the
list.

> > I think there are good justifications to rolling a highly conservative
> > 1.4 release.
> >
> > There are some roadblocks which are starting to be painful in 1.2
> > (especially hard coded max-jobs), which require action on the one hand,
>
> I'm assuming this set is small, and a small delta to 1.2?

That is my aim, I think the biggest change to backport is the ability
of Sources to observe previously fetched/tracked sources, so that we
can implement a plugin for cargo similar to the one we have for pip.

I don't want to push for more than a couple of things, at the same time
I don't want to deny other backports entirely if Abderrahim wants to
put in some work for that (but even there I want to be extremely
conservative, we shouldn't embark on a diverging codebase here, just
remedy the real problems).

> > and on the other hand there are some conveniences introduced in master
> > that are extremely unlikely to change (e.g. 'build-depends' and cross
> > junction colon notation for dependencies).
>
> My opinion: if you need those, track master.

I don't think this is a realistic option right now, it might be once we
have a release date in mind for BuildStream 2, and we have a better
idea of what will and wont change.

Master is still a fast moving target, I'm not comfortable working with
it for production purposes (especially we are looking at a huge
incoming churn in plugin locations, dates still unknown, we cannot have
this happen in the middle of a flatpak runtime release for instance).

BuildStream needs to be both easily installable and stable for the
projects which leverage it in the wild.

The freedesktop-sdk and GNOME projects need to be able to say "Just
install BuildStream and build it", and that has to be the same reliable
experience for everyone who wants to work on these project.

We can't afford situations where downstream projects buy into a new API
 or feature, which then changes in master a month or two later and then
breaks (some projects can of course buy into a fast changing master,
but I would not recommend that for freedesktop-sdk or GNOME).

> > Judging from the meeting, I think there is also large consensus that we
> > should not be backporting things that are at all likely to change (e.g.
> > the CLI interfaces).
> >
> > While technically BuildStream 2 is a separate beast and it will
> > certainly differ from BuildStream 1 in some ways, it is highly
> > desirable that their paths do not diverge - for example, if we backport
> > things from BuildStream 2 and those APIs change for whatever reason,
> > then we will be stuck with the ugly story of having more than one
> > porting guide for porting to BuildStream 2, I think we would do well to
> > stay extremely conservative and avoid any such situation.
>
> And even when being conservative that won't be a guarantee, as there may be new insights. 

Right, hence the prefix that technically BuildStream 2 will be a
separate beast, it has already diverged from BuildStream 1 - and if we
do backport something that is not included in the end in BuildStream 2,
it will be very unfortunate (but not the end of the world).

This should not place any additional restrictions at all on what is
being done for BuildStream 2.

Cheers,
    -Tristan