Re: [BuildStream] Buildtrees in 1.4 release

[William Salmon <will salmon codethink co uk>]

On 30/11/2018 06:28, Tristan Van Berkom via BuildStream-list wrote:
> Hi Laurence,
>
> On Thu, 2018-11-29 at 21:47 +0000, Laurence Urhegyi via 
> BuildStream-list wrote:
> <snip>
> > If we're being honest, it's looking unlikely that we'll be able to set
> > configuration options for creation and pushing in time for 1.4.
> >
> > Is this really acceptable to users, to not have these be optional?
Given the issues in Gitlab and explained below it seems like this is a 
big issue for at least two.
> > I'd like others to weigh in here but I feel like hiding this feature
> > with an experimental flag is the right thing to do for the  1.4 release.

Tristan eludes to my point later so I'm not sure about ML etiquette 
about putting this text hear.

I think this question can not be answered until we can understand and 
thus trade off the cost of delaying 1.4 vs disabling them.

Were we do this for the 1.4 branch but not master, would need to leave 
time to have a really good shake down of bugs this might introduce? And 
then any back ported fixes might be even harder? A flag might be even 
more complex.

My guess would be that a delay would be cheaper, however i am not 
familiar with the costs of delay, so its just a guess.


> A few things to say here:
>
> * Enabling build tree creation to unblock the surrounding feature
> work was the first thing we did when early branching for 1.2
>
> Which means we have had more than an entire release cycle to
> make this work perfectly - having to back this out now, would be
> very sad.

I agree that this would be very sad.

> * I am doubtful of the importance of any option for *creation* of
> build trees, especially now that we have local cache cleanup
> in a robust enough state.

Multiple people have found the user experience on a "realistic" project, 
un-usable, due to it being incredibly slow. 
https://gitlab.com/BuildStream/buildstream/issues/734 and 
https://gitlab.com/BuildStream/buildstream/issues/754.

> In other words, the local cache only needs to be large enough
> to store the sources, build trees and build results for a single
> full build - this is the same amount of local disk space required
> for a full build using say, JHBuild.
>
> Has anyone even raised an issue or proposed that *creation* of
> the build trees should be optional ?

I thought the idea was that buildtrees in the whole would be optional if 
the local clean up worked this may never have been a issue.

I would propose that the issue is not their creation, as i think this is 
needed to create cache keys etc but the inability to not add them to the 
local cache. How ever this is a technicality to a user.


> * If there are other features that we've been planning for 1.4
> much later in the cycle that are not landed yet, it makes a lot
> more sense to postpone those in order to ensure what we've already
> landed works seamlessly, than to start backing out previous
> features.

+1

> Finally, I wanted to make a statement soon about the release dates but
> didn't judge that people were going to be panicking this week yet.
>
> The point is that, we're trying to move the release cycle to be earlier
> in order for our releases to be more conveniently *before* our regular
> hackfests and meetups, rather than releasing directly after our
> meetups.
>
> This totally makes sense for the sake of the meetups, but the quality
> and reliability of the release is certainly more important than the
> convenience of our meetup.
>
> Maybe we were overzealous in moving the release dates too early too
> quickly, and it will make more sense to keep it at the regular date for
> 1.4 (I think that puts release day in early March and feature/API
> freeze in February).
+1
> It makes no sense for people to be developing in a state of panic, and
> since we did try to change the release dates in mid cycle, not doing so
> this cycle is a lot less drastic than backing out features.
+1
> Cheers,
> -Tristan
>
> _______________________________________________
> BuildStream-list mailing list
> BuildStream-list gnome org
> https://mail.gnome.org/mailman/listinfo/buildstream-list