BuildStream Monthly Team Meeting
Date and time: Tuesday 17 October, 14:00 UTC.
Agenda
Blockers for BuildStream 1.0 release
Suggested by: Tristan Van Berkom
No feature additions beyond the recent format changes we agreed on, we'd just like to shake the tree and get a hold on what bugs need to be closed for a 1.0 release.
Release Schedule
Suggested by: Laurence Urhegyi
We should discuss how/if BuildStream releases will align with GNOME releases. Also I think we should inform everyone about the release cycle and also the devel / stable branch (more of an 'announcement' than a discussion perhaps).
Next meeting date
Suggested by: Laurence Urhegyi
Exactly 4 weeks from now? That would be Tuesday 14 November. Then every 4 weeks re-occurring?
Any other business
Suggested by: Laurence Urhegyi
Chance for anyone to raise anything not already discussed.
Minutes
Actions from the meeting:
ACTION: Tristan to arrange the bot for next meeting.
ACTION: Tristan to update the bug list with blocker bugs.
ACTION: Tristan to raise a gitlab issue re the behaviour change for bst build --track.
Minutes as per each agenda item:
Blockers for BuildStream 1.0 release
1) Stricter errors on overlaps - https://gitlab.com/BuildStream/buildstream/issues/114
Outcome: BLOCKER.
Edit: We later decided this was NOT A BLOCKER.
2) Multiple Cache Support - https://mail.gnome.org/archives/buildstream-list/2017-October/msg00012.html
Outcome: NOT A BLOCKER.
Could break user configurations, but backwards compatibility there is ok.
Points to note on this one:
- A one time break will be expected and noted in release notes (for artifact client side URI configuration only).
- Further discussion will be needed on the policy of breakage of user configuration.
3) Distinguish between tracking and saving in bst build --track
Outcome: BLOCKER
Points to note on this one:
<sstriker> The current behaviour of bst build --track is to do recursive tracking
<sstriker> Which is not always desired (I'd argue it usually isn't)
<tristan> Ah, very good point
<tristan> in contrast with bst track
<sstriker> I suggest a behaviour change before 1.0
<tristan> Yes, I concur, I'm not sure what it will be, but will file a bug
<tristan> it could be multiple --track <element> --track <element>, or it could use a config file
4) Apply pep 3102 to all public API surfaces - https://gitlab.com/BuildStream/buildstream/issues/97
Outcome: BLOCKER.
5) Need early exit and comprehensive error when host kernel lacks CONFIG_USER_NS - https://gitlab.com/BuildStream/buildstream/issues/92
Outcome: NOT A BLOCKER.
This is more about good user experience, not vital for first stable release.
Release Schedule
Summary of discussion:
# Allignment with GNOME Release Schedule:
tristan: I'll note that I will not tie GNOME to stable BuildStream 1.0
- There's a difference between following the GNOME release schedule, and tethering the releases.
GNOME releases need not block on BuildStream in general
- I.e. not tethered... however, following the schedule for our stable releases is orthogonal for that
- Anyway, following the schedule is strongly encouraged but doesnt matter a great deal in reality...
- I would posit that we target the *next* GNOME release... I think 3.30, as our second stable
doing it on a 6 month cadence alongside GNOME, is not a problem; its all around good stuff to do 
- I'd like to also follow GNOME style release numbering
- ie. even minor number = stable, odd minor number = devel
# Build up to a release: * <tristan> And I would "generally" like to follow the hard dates, but... * some things don't apply to us, eg. string freeze, which we can ignore for now. * We should go for: API freeze one month before code freeze, and then release. * This means we can develop an internal model where we * A.) Land bigger features early in the cycle... * B.) Reject features after a feature freeze... * C.) Leave us some time to address issues before release, without new features landing
# Length of support of buildstream releases: * We should continue to backport bug fixes to our stable branches, for the stable versions which are still required by GNOME maintained modulesets * at least" as far back as maintained GNOME stable releases go.
Next meeting date
Every 4 weeks is agreed.
Need to discuss the time zone...maybe best not to keep to UTC.
Future uildStream meetings to take place in #buildstream-meeting on GIMPNet.
Any other business
None.
See full log here.