Re: [BuildStream] Proposal: More development snapshots, more often

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

Hi Chandan,

A bit late to the party...

On Tue, 2019-09-10 at 00:26 +0100, Chandan Singh wrote:
> Hi all,
>
> BuildStream 2.0 has been under development for quite some time now.
> Over this time, many things have changed - plugins are moving out, we
> are in process of gaining and losing various dependencies (buildbox,
> fuse etc).

So yes I've been wanting to do this for a very long time too.

On my side, I've been blocking myself from proactively rolling out a
snapshot on first landing the (fairly trivial) patches which ensure
parallel installability first.

I think that when we publish a snapshot, the point is that people can
try it out and we can get meaningful (and hopefully positive) feedback,
for that to happen we should at the very least ensure that it installs
easily and doesn't conflict with an existing BuildStream installation.

That said, there has been some pushback and I haven't been actively
stressing this issue (which I still think is very important for the
project).

At this point, there is much to do in terms of custom dependencies you
wont even find on your distro, so I would suggest that we pay attention
to our install guide, ensuring that it is easy to find the instructions
which correspond with the snapshot you try to install.

Cheers,
    -Tristan


> Not providing a good indication for these changes makes it difficult
> for anyone trying to follow BuildStream's master. So, I would like to
> propose tagging more development snapshots. This would help anyone who
> is managing a copy of BuildStream using something like BuildStream (or
> BuildStream itself).
>
> Same as the master branch, these snapshots will not come with any sort
> of guarantees. They will not be expected to maintain
> backwards/forwards compatibility. Also, they will serve merely as a
> tagging mechanism. They would _not_ require to be maintained or
> patched in future.
>
> I think this is a relatively small workflow change to do. But, it will
> make life a bit easier for anyone trying to consume BuildStream's
> master. I belive such real-world testing is very important. For
> example, we recenly identified a bunch of grpc-related issues when
> trying to update our copy of BuildStream. Such issues might be go
> uncaught if we don't make it easy for people to test new versions.
>
> For making these snapshots, there doesn't need to be a big ceremony,
> other than creating a tag on GitLab. It would be good to do so when
> adding/removing any external dependencies, making breaking changes, or
> other major changes. This would also give us the ability to
> meaningfully reference these points in history, rather than
> remembering them by their commit ids.
>
> Additionally, I have noticed some of us already put NEWS entries for
> such changes. If we make it a convention to follow this, the NEWS file
> will also serve as a handy guide for anyone maintaining their version
> of BuildStream.
>
> Let me what you think of the idea. Thanks!
>
> Chandan
> _______________________________________________
> buildstream-list mailing list
> buildstream-list gnome org
> https://mail.gnome.org/mailman/listinfo/buildstream-list