Re: Building BuildStream with BuildStream (dog-fooding)

[Sander Striker <s striker striker nl>]

Hi,

On Mon, Jun 4, 2018 at 6:24 PM Tristan Van Berkom <tristan vanberkom codethink co uk> wrote:

On Tue, 2018-05-29 at 22:23 +0100, Laurence Urhegyi wrote:
> Hi,
>
> I'd like to start a discussion about dog-fooding with BuildStream. I think there 
> are some clear benefits to this:

There are two sides to this I think:

  o Using BuildStream to create OS packages of BuildStream

    This is somewhat interesting, as it lets us test out and
    mature the packaging stories (e.g. building .debs or .rpms).

    There is notably "not much to build" when you talk about just
    building BuildStream itself, but this might change with the new
    fuse layers being discussed.

    The downside of this, is that it's most probable that the actual
    packages we produce here would be the ones distributed by distros,
    so you dont get that one bird with 3 stones effect... in the end
    this activity would not "really" be dogfooding, but still a
    worthwhile exercise.

I think this covers one aspect, but it's likely too far removed from

developers (e.g. running in CI).

 

  o Using BuildStream to produce a system which can run BuildStream

    This is more interesting as an integration test for the source
    bundling code paths which spit out scripts for building on another
    machine (only supposed to be necessary for bootstrapping on new
    machines).

    This is a lot more involved, but covers a lot of stuff we currently
    lack in CI (possibly work from freedesktop-sdk project could be
    shared to facilitate this).

    Maybe this could result in nightly built docker images which could
    be used with the `bst-here` script.

I think there is also:

Using BuildStream local development workflow to work on the project.

That is, use bst workspace open, and bst build to create your new bst.

That will expose us to using these commands day in day out.  Ditto

for bst shell and friends.

I do think that with the FUSE layer in the mix this will be more

interesting as we'll start to cross element boundaries then.

Cheers,
    -Tristan

Cheers,

Sander

 

>
> * Demonstrate confidence in BuildStream.
> * Increase the amount of real world use cases, thus identifying more bugs.
> * Mitigating against the risk of developers working 'in a vacuum', by ensuring 
> developers are also users of the tool.
>
> There is a risk that this will prove more difficult than anticipated, and 
> potentially serve as a distraction that does not bring as much benefit as 
> desired, but I think this risk is quite low, overall.
>
> Anyway, there are people involved in the project who are much more informed on 
> the matter than I. So far, having spoken to people informally about this, there 
> seems to be a general consensus that this is clearly a good idea, but 
> BuildStream is probably not yet ready for it. I welcome all thoughts on this. Is 
> anything currently blocking it from happening that you know of? I have also 
> opened up a gitlab ticket for this:
>
> https://gitlab.com/BuildStream/buildstream/issues/410
>
> Thanks,
> Laurence
>
>
>
> _______________________________________________
> Buildstream-list mailing list
> Buildstream-list gnome org
> https://mail.gnome.org/mailman/listinfo/buildstream-list
>

_______________________________________________
Buildstream-list mailing list
Buildstream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list

--

Cheers,

Sander