Meeting minutes, 17 October 2017 (was: monthly IRC team meetings)



On 16/10/17 10:15, Laurence Urhegyi wrote:
<snip>
OK so since there were no objections to this time and date, we'll hold this meeting tomorrow at 14:00 UTC, on #buildstream on GIMPNet.

All,

We just held the meeting. Minutes below.

wiki is updated, where you can also see the full log, should you wish:

https://wiki.gnome.org/Projects/BuildStream/Monthly-Meeting/20171017

========================================================================

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.

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
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 BuildStream meetings to take place in #buildstream-meeting on GIMPNet.

=== Any other business ===

None.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]