Hi Abderrahim,

On Sun, 2022-01-09 at 19:06 +0100, Abderrahim Kitouni wrote:
> Hi all,
> 
> Allow me to start my reply with a rant. I don't like how the project
> is run right now. I think it would be better to invite non-core
> contributors and prominent users of buildstream to such meetings. I
> understand that it might not be possible if such meetings are held in
> person, but it would be nice to at least announce the meeting
> beforehand and allow them to weigh in (even if they're not allowed to
> vote).

Well, fair enough.

>From my perspective, I have very little time available to get others
together so I'm very satisfied that after many months I was able to
gather 5 people in the same meeting room for 2 hours, and make some
executive decisions which help us to get this show back on the road.

> I'll add my comments inline.
> 
> Le dim. 9 janv. 2022 à 02:48, Tristan Van Berkom
> <[email protected]> a écrit :
> > The new milestone overview, which dictates what we expect to land before
> > our first candidate release, can be viewed here:
> > 
> >     https://github.com/apache/buildstream/milestone/2
> 
> I think buildstream has a lot of rough edges right now to even
> consider a release candidate. I would consider this what needs to be
> done before a beta release, and then we'll need some serious bug
> fixing before a release candidate.

Sure, a beta release is a better word to use than a release candidate.

The *really* important point though is that we reach the hard API
freeze, which is a point at which we can actually tell users that
BuildStream 2 (beta or otherwise) is safe to use.

Once we reach that point, I think we can expect the project to get some
momentum again.

That said, thanks for collecting and sharing these links !

> I'd add to the list
> https://github.com/apache/buildstream/issues/1263
> I think this is potentially (Caching buildtrees only works with BuildElement)

This, I think what we're really talking about here is script elements,
or similar concoctions, and we probably don't want to cache anything
for a variety of elements (like compose or filter elements).

I think this can be easily solved with some policy though:

  a.) If you think your element should have a build tree that gets
      cached, then structure your element such that what you want
      to be cached is under `%{build-root}` (of course the element
      implementation can also *set* `%{build-root}`)

  b.) Don't have the expectation that all elements under the sun
      will cache their build trees, instead exit more gracefully
      with an informative error explaining that the element in question
      does not provide support for this.

I'll comment back on the issue, not sure that I'd want to block a beta
on this but blocking a real release could make sense. It also makes
sense to have separate beta/release milestones in github so we can
better track this stuff.

> This should definitely be considered as it would affect cache keys:
> https://github.com/apache/buildstream/issues/1270
> 
> There is also this that we want to either accept or close as wontfix.
> https://github.com/apache/buildstream/issues/1384

Added these two to the milestone.

> Then there is a long list of bugs that need to be fixed (a lot of them
> are about non-strict mode). These would be fine to leave after the
> beta.
> https://github.com/apache/buildstream/issues/1304
> https://github.com/apache/buildstream/issues/1352
> https://github.com/apache/buildstream/issues/1360
> https://github.com/apache/buildstream/issues/1394
> https://github.com/apache/buildstream/issues/1455
> https://github.com/apache/buildstream/issues/1460
> https://github.com/apache/buildstream/issues/1461
> https://github.com/apache/buildstream/issues/1465
> 

Yeah a lot of buggy behavior probably needs to be tracked in a second
milestone.

> 
> > Meeting minutes
> > ===============
> > 
> >  * Walk back over zealous plan to disallow writing in the sandbox
> 
> I think this is nice, it allows for some really nice optimizations. It
> should probably have an explicit API and a big fat warning about it
> though.

Agreed, that needs to be thought out when reviewing the Directory API:

    https://github.com/apache/buildstream/issues/1294


Thanks a lot for the feedback !

Cheers,
    -Tristan


Reply via email to