Meeting minutes, 17 October 2017 (was: monthly IRC team meetings)
- From: Laurence Urhegyi <laurence urhegyi codethink co uk>
- To: buildstream-list gnome org
- Subject: Meeting minutes, 17 October 2017 (was: monthly IRC team meetings)
- Date: Tue, 17 Oct 2017 17:04:13 +0100
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]