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.

Projects/BuildStream/Monthly-Meeting/20171017 (last edited 2017-10-24 09:40:56 by LaurenceUrhegyi)