<ltu> OK, shall we begin?

<tristan> Yay \o/ !

<tristan> nice turnout

* tristan tries to resolve wiki... slooowly

<sstriker> indeed

* tristan resorts to email

<tristan> sstriker, nice to see you around here

<ltu> tristan, shall we ask folk to confirm if they're taking part with a raised hand or something?

<tristan> ltu, lets start, I just realized

<ltu> I'm not sure on the protocol: that may not be required.

<tristan> GNOME is having a mass reboot session

<ltu> ok

<tristan> hence lack of wiki

<ltu> alright so item one:

* persia laments the lack of mootbot

<ltu> === Blockers for BuildStream 1.0 release ===

<ltu> Suggested by: tristan

<ltu> '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. '

<ltu> ....

<tristan> Alright thanks ltu

<ssam2> o/

<tristan> So for me this has been an invaluable exercise when initially releasing Glade, it may be less intensive because we already have some eye

<tristan> s

<tristan> What I'd like to get out of this agenda point, is a clearer picture of what we are comfortable with in terms of tidying up before 1.0

<tristan> ssam2... go ahead

<ssam2> was just going to suggest two things on my plate which would break things

* daniel (45bfb021@64.62.228.82) has joined

<ssam2> 1 being the multiple cache support proposal, and the other being stricter errors on overlaps

<tristan> Right, OK - as this is a bit more involved than agenda points... I have a scratch area I'm going to collect

* daniel is now known as Guest64284

<tristan> Ok, I think stricter errors on overlaps is reasonable

<tristan> Is there a reason why we think multiple cache support should block 1.0 ?

<sstriker> Overlaps in terms of produced files?

<ssam2> in terms of: i stage 3 dependencies and each provides /bin/sh

<persia> sstriker: In terms of two elements that have the same file, where only one can be in a combined element.

<sstriker> *nod* thanks

<ssam2> multiple cache support could break user configurations

<ssam2> i guess we could have backwards compatibility though

<ssam2> so doesn't really need to block 1.0

<tristan> ssam2, that is a good point

<persia> Could or must? If must, I wonder if we can add something to make it could in 1.0. If could, can there be a simple migration script for users?

<tristan> However - I feel that one time breaking user configuration post 1.0 for this is not a huge concern

<sstriker> I concur

<juergbi> would be nice to avoid it, though

<ssam2> fine by me

<persia> Nice to avoid, but part of the signal sent by a new major version number is the potential to break config. Difference between 1.1 and 2.0

<tristan> juergbi, certainly - and I would like it to be stable in 1.2 (or whatever is "next stable")

<ssam2> i think backwards compat is not too hard, the current proposal suggests replacing the dict with a list. we can handle both cases

<tristan> Back compat for user configuration will be doable, but I believe we need to break it once for canonical URIs

<tristan> Which I believe is orthogonal to multiple cache support

<ssam2> my understand is you want it as a prerequisite

* persia is unconvinced that the canonical URI design is sufficiently complete to avoid delaying the 1.0 release for a long time

<ssam2> but the old URIs would continue to work

<ssam2> *my understanding

<tristan> ssam2, yes - would they ? that would be relatively high cost and annoying no ?

<ssam2> on the server side, no changes needed at all

<ssam2> client side... it doesn't /seem/ bad, but i have been wrong before

<tristan> ssam2, however it imposes something on the server side which is inconvenient, I think

<juergbi> i also wouldn't expect it to be high cost but haven't thought about it much

<tristan> ssam2, I.e. we always have to continue supporting ssh push / http pull - for linux, forever

<tristan> ssam2, whereas, with a single uri, if we change things behind the scenes, no big deal

<tristan> In any case I think this is not a huge point of contention

<tristan> My thoughts are that A.) we can break configuration API once for the sake of canonical URI for push/pull ... and B.) that need not block 1.0

<tristan> But a one time break will be expected and noted in release notes.

<tristan> (for artifact client side URI configuration only)

<tristan> That would make it, not a blocker - Is that alright ?

<ssam2> fine by me

<juergbi> ok, but i would keep compatibility, if it's easy enough

<sstriker> I can live with that

<tristan> juergbi, what I certainly dont want, is a gray area where we "try to keep compat" long term without a promise

<tristan> juergbi, which is why I feel like ironing out the kinks once and explicitly breaking, is nice

<tristan> it allows for a point of no return, and stricter future

<persia> I want that. I would like to see compatibility kept for everything, if possible, but only a few promises, as too many constrain too much.

<tristan> Agreed, it is for certain that; when we make aggressive changes to the artifact server... sysadmin work will be required

<tristan> However that should be doable without breaking client config

<juergbi> do we want a version number in config files?

<tristan> Alright - I'm marking this down, we're straying off course - it's not a blocker, but further discussion may be needed on the policy of breakage of user configuration.

<juergbi> fair enough

<tristan> juergbi, My thought is no, until we do

<tristan> That is largely a bridge we can cross when we get there

<persia> If we think we will want a version number in the future, better to start with one now.

<juergbi> agreed

<persia> Crossing the bridge later is painful.

<juergbi> no version can be considered 'version 1' or so

<tristan> persia, a versionless configuration file, is version 0, or 1

<tristan> exactly

* persia has crossed that bridge lots of times, and is always happier when someone has already thrown a rope over the span

<tristan> persia, in other buildstream cases, you are correct, I disagree about this one.

<tristan> As this was raised - I'm marking it down

<tristan> Initial Revision for configuration

<tristan> However, I dont think it's a blocker

<tristan> I have only 2 blockers on the list as of now (I meant to spend time reviewing what I wanted to add, but then didnt :-/)

<tristan> I should at least enumerate those

<tristan> - https://gitlab.com/BuildStream/buildstream/issues/113

<tristan> The above is distinguish between bst build --track and bst build --track-save

<persia> GNOME finished rebooting: shall we use https://etherpad.gnome.org/p/buildstream20171017 for notes?

<tristan> Because bst build --track will have a possibly unwanted side-effect of rewriting the project

<tristan> persia, after the meeting, ltu will be updating the wiki with action points and such

<tristan> ltu, and here is one

<tristan> ACTION: Tristan to update the bug list with blocker bugs

<ltu> ok

<tristan> So, I dont think there is any contention for issue 113, I've discussed it with Sam, and it's fairly simple to do

<tristan> And not doing it before 1.0 means we break things if we ever do it later

<juergbi> agreed

<tristan> The other is https://gitlab.com/BuildStream/buildstream/issues/97 - Apply pep 3102 to all public API surfaces

<sstriker> we should definitely do those

<sstriker> Can I continue on the track one for one more min?

<persia> +1 on landing 113 before 1.0

<sstriker> More related, not the same

<tristan> sstriker, yes please sorry to get ahead

<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> Right

<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

<tristan> but lets brainstorm that separately

<sstriker> +1

<sstriker> Assume that is a potential blocker due to behavioural change

<tristan> Certainly

<tristan> So... moving on... (mini timer in my head...)...

<tristan> pep 3102 is a nitpik of mine, but means a stronger python API surface

<persia> I like pep 3102, but feel like it could be added later, if nobody gets around to the tedious bits.

<sstriker> +1 on that one. Will reap benefits later

<persia> As long as there are no major API changes between 1.0 and 1.2, safe to defer. If major API changes are expected, then we should do now.

<tristan> What it means is: def function(positional1, positional2=default_value, *, keyword_arg1=default_value...)

<sstriker> Not sure that it can, given positional arguments?

<juergbi> strictly speaking, it breaks backward compatibility, so +1 as blocker

<tristan> So, if everything distinguishes, and positional arguments (possibly with default values) are reduced, it means that we can always move args to become positional, but not the reverse

<tristan> So it really is a thing about back compat of API

<tristan> persia, yes it implicitly breaks API, and adds a measure of protection for future extensibility

<sstriker> +1 for taking this hit now rather than later

<tristan> Ok, marked that...

<tristan> Has anyone any other blocker ideas ?

<tristan> I am tempted to consider things such as: Need early exit and comprehensive error when host kernel lacks CONFIG_USER_NS - https://gitlab.com/BuildStream/buildstream/ issues/92

<persia> I would like a canonical artifact serialisation format, but I don't know whether that needs to be defined before the first release or can come later.

<tristan> persia, serialization format; do you mean: Stability of artifact content as an API surface ?

<persia> Probably

<tristan> Well, ssam2 and I discussed this here today briefly

<tristan> But I feel like this is better punted to second stable line

<tristan> Lets take some more time to learn about this before calling this part stable

<persia> I'm fine with punting, if it is safe to punt. Just wanted to check.

<tristan> Thoughts ?

<sstriker> tristan: while #92 is annoying, I'm not sure it is a blocker.

<tristan> sstriker, yeah; I was going to ask if I should be considering these

<sstriker> They can be addressed in patch releases

<tristan> There are annoying things, like the ^C behavior in the interactive shell, which are also annoying

<tristan> But things about not detecting the dependencies well and having unpleasant surprises, mean immediate fail for some new users

<sstriker> Won't break backward compat though. Question is what do you want the experience bar to be for 1.0

<tristan> But I'm personally ambivalent about calling that a blocker

<juergbi> maybe mark it as nice to have for 1.0?

<sstriker> Becuase if we consider these things we open up the door for a number of others

<tristan> sstriker, that is also a _very_ good question

<tristan> Ok - so in the interest of sure footed progress, I will disregard those from blockers.

<persia> Given the timing, I think 1.0 should prefer a safe and likely backwards-compatible API to user experience. For 1.2, there are lots of things to make it better, but more users sharing how they experience it will help us make that list.

<sstriker> staging performance, startup performance, incremental builds, would be what springs to mind. Think that's better left for next point release if we are on a timed release schedule.

<sstriker> +1, exactly.

<tristan> I'll note that I will not tie GNOME to stable BuildStream 1.0

<tristan> But will hope that in the future we can depend on stable BuildStream, perhaps via distro packages

<persia> tristan: I think GNOME can move to 1.1 without an issue. But I think long-term, it would be nice to release BuildStream simultaneously with GNOME, and have the released BuildStream work with the released GNOME for the life of both.

<tristan> persia, that still implies that GNOME will use unstable buildstream internally in advance of a release

<persia> tristan: Yes, and intentionally

<tristan> persia, which I think is "okay", but will hope to avoid after one or two release cycles

<sstriker> I am not sure it is desirable to tether the releases

<tristan> If it does happen, it will be because of an explicit feature request from GNOME

<tristan> indeed, it creates friction

<persia> I think it is important to allow GNOME to do that, but not to force GNOME to do either.

<tristan> That will be discussed in the next agenda point though I think.

<tristan> So... lets wrap this up first

<tristan> I dont have other blockers on my plate

<tristan> Anyone ?

<tristan> Ok

* tristan simultaneously ran through the buglist to double check.

<tristan> ltu, since you announced the last one, would you like to do the honors ?

<tristan>

<ltu> alright

<ltu> I think a lot of it will have just been covered then

<ltu> second agenda point is:

<ltu> === Release Schedule ===

<ltu> '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).'

<persia> I was under the impression that, as a GNOME project, BuildStream was strongly encouraged to follow the GNOME release schedule. In practice, I don't think it matters much.

<tristan> Ok so before we split hairs, lets note the difference between following the GNOME release schedule, and tethering the relases

<tristan> The difference I see here, is that GNOME releases need not block on BuildStream in general

<tristan> I.e. not tethered

<tristan> Following the schedule for our stable releases, I think is orthogonal for that

<tristan> *to

<tristan> Also persia is exactly correct; strongly encouraged but doesnt matter a great deal

<sstriker> Concur. I also like the "strongly encouraged" vs "must"

<sstriker> (not suggesting we don't at this stage)

<tristan> So, if people are unfamiliar with the GNOME release schedule, it's pretty simple: https://wiki.gnome.org/Schedule

<tristan> I would posit that we target the *next* GNOME release... I think 3.30, as our second stable

<tristan> Giving us more time for our first cycle, because we're late to the party anyway

<persia> So, the concern I was expressing earlier is that I think that if GNOME modules have BuildStream definitions, the BuildStream version that supports those definitions should be maintained about as long as those modules, just from an end-user experience point of view. It might take a couple cycles to get there.

<tristan> And I would "generally" like to follow the hard dates

<tristan> Ah

<tristan> persia, that is not in our court, however

<tristan> persia, with my brand spanking new release team hat on however, I can say that in general there is some maintenance at least of last stable

<tristan> jjardon[m], could enlighten us more, though.

<persia> How is the length of support of some release of buildstream not in our court?

<tristan> persia, Ahh ok I misunderstood

<persia> Right, so I just want the BuildStream release & support model to be something that would allow the behaviour I described. Whether otherr folk in GNOME decide to do so is up to them.

<tristan> So you mean, that we continue to backport bug fixes to our stable branches, for the stable versions which are still required by GNOME maintained modulesets.

* persia may go discuss the matter with them, but that is outside the scope of this meeting.

<tristan> persia, does that match your thinking ?

<tristan> I.e. "at least" as far back as maintained GNOME stable releases go

<persia> Some bug fixes: there's a difference between "crashes", "misspelling happens to be a disturbing word", etc. and "not as fast as I want".

<persia> But otherwise, yeah.

<tristan> Ok, I certainly approve

<tristan> It may one day come down to a matter of resourcing

<tristan> but lets ride with that

<persia> It always does

<tristan> So asides from this; When I say I would "generally" like to follow the hard dates - I also feel that some of this does not apply to us, in the same way as it does for GNOME

<tristan> I.e. we wont have string freeze - until such a day that we might implement i18n properly for our frontend(s)

<tristan> And, I dont think we care about UI freeze either, this is very centric to how documenters/designers are preparing what the next "GNOME UX" will look and feel like

<juergbi> yes, i think we can ignore those

<persia> More generally, I suggest BuildStream not observe freezes until there is a group that is separate from the developers that needs to do follow-on preparation work for release.

<tristan> But an API freeze one month before code freeze, and then release; seems reasonable to me

<persia> So, if there are translation volunteers, honor string freeze, etc.

<tristan> persia, right; for translations; we would need to first do work to make it translatable

<tristan> but yes

<tristan> For us though, it 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

<tristan> persia, this is something I want, and will reduce cost of maintenance overall

<sstriker> that sounds sane

<juergbi> i agree

<tristan> So, to me, doing it on a 6 month cadence alongside GNOME, is not a problem; its all around good stuff to do

<ssam2> +1

<sstriker> +1

<tristan> Alright, ltu; would you like to take the action of summarizing that somewhere on the wiki ?

<tristan> or would it be rude to voluntell you that

<tristan> heh

<ltu> sure, doing it atm

<ltu>

<ltu> that's exactly what i wanted to email out after the meeting and confirm

<tristan> ACTION: ltu to summarize release schedule policy from our discussion

<ltu> alright, last point on the agenda, a nice easy one:

<ltu> === Next meeting date ===

<ltu> Exactly 4 weeks from now? That would be Tuesday 14 November. Then every 4 weeks re-occurring?

<jjardon[m]> tristan: what is the question? R-T only maintains the current stable and the next release (current unstable)

<tristan> ltu, I think you're a bit quick on the trigger there

<ltu> hhmm, ok...

<tristan> jjardon[m], ok - good to know

<jjardon[m]> tristan: actually, we support the current stable only for a while, until we release .2

<tristan> In any case; I think we've spoken enough about that, but just in case - Anything that we should be getting straight about BuildStream's release cycle ?

<jjardon[m]> then is the community who upgrade the modulesets, if needed

<tristan> jjardon[m], please - this is not random discussion, we're having a monthly team meeting right now

<tristan> jjardon[m], if you would like to join, just please follow the discussion

<jjardon[m]> tristan: you ping me

<tristan> I mentioned you yes...

* jjardon[m] dissapears

<tristan> Ok... Any other points to discuss about BuildStream release schedule ?

<tristan> Just wanted to give people a chance to ring in...

<tristan> Ok sorry ltu - next point then

<tristan> === Next meeting date ===

<ltu> yeah, sorry for jumping ahead there.

<persia> I like every 4 weeks rather than every month.

<ltu> makes more sense to me.

<tristan> So that is fine with me

<tristan> Also always lands on a tuesday, nice - no mondays no fridays is a rule I think

<sstriker> +1 here too. I'm assuming this is the best time for everyone?

<tristan> I think so, I mean I have to be up late, but it's only me and I dont mind, and 10 am EST is nice and after first cup of coffee

<tristan> while BST lands in midday

* persia has lots of IRC meetings on Tuesdays, making it a very good day. This also happens not to conflict, if we assert it stays 14:00 UTC, and doesn't move.

<tristan> Oh !

<tristan> Wait

<juergbi> DST is ending in Europe/US before the next meeting

<tristan> You guys are going to run one hour away

<juergbi> do we keep UTC or British time?

<persia> tristan: 14:00 UTC will always be the same for you. Just some folk have to change.

<tristan> persia, ah thanks

<tristan> yes

<juergbi> yes, probably best

<ltu> I was thinking to always keep to UTC.

<ltu> OK so that seems to be confirmed then. I'll remind everyone one week before the next meeting of course

<persia> Nice thing about keeping UTC is that it avoids the annoying times when different governments do DST on different schedules. Doesn't affect us now, as most folk change before the next meeting, but it could in the future.

<sstriker> kk, i'll need to change some things on my end to make that work. UTC is a bit painful, as it tends to conflict with meetings that do move with US timezone

<sstriker> There is exactly 4 weeks of the year where timezones are out of whack. I'd rather take that than a meeting that is on a different time depending on half of the year

<tristan> Ummm

<tristan> I propose we move this to a side channel

<tristan> For future meetings

<sstriker> kk

<persia> +1 on discussion of timezones after the meeting

<sstriker> 4 weeks we can settle on

<tristan> I have no issue with lurkers at all, and encourage it; but better to avoid distractions from gitlab bots and those who, very understandably, have no idea we're having a meeting

<tristan> so -> #buildstream-meeting, and log the minutes

<juergbi> ok, sounds fine to me

<ltu> ok

<tristan> So that's not a huge agenda point

<tristan> shall we open the floor for any other points ?

<ltu> tristan, the other other thinh i had was: === Any other business ===

<ltu> thing*

<tristan> ltu, exactly

<ltu>

<gitlab-br-bot> buildstream: merge request (102-run-ci-as-non-root-user->master: Resolve "Run CI as non-root user") #104 changed state ("opened"): https://gitlab.com/ BuildStream/buildstream/merge_requests/104

<gitlab-br-bot> buildstream: merge request (102-run-ci-as-non-root-user->master: WIP: Resolve "Run CI as non-root user") #104 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/104

<tristan> So, in the future with a #buildstream-meeting channel happening exclusively for meetings; we can always just end with that

<sstriker> I think we would be getting ahead of ourselves if we discussed what the focus would be for beyond 1.0. Maybe more for next meeting.

<tristan> And people can feel free, but not obligated, to hang around longer

<tristan> Unless there are any adamant points raised last minute, hopefully they can be raised directly before the meeting

<tristan> sstriker, agreed, that is also quite an open topic we cant discuss very efficiently right now

<tristan> Actually, we should probably be doing that next week yes

<tristan> *month

<tristan> next 4 weeks... because assuming we're closing in on first stable; we should be looking at those mountainous feature branches that contributors have their mouths watering and wanting to land

<tristan> And thinking, lets get to merging this early-cycle

<tristan> sstriker, like that ?

<persia> Indeed: by next time, we should have released, and be able to merge a few things and discuss the remainder.

<tristan> I had not observed the timing of it but indeed it's already close to "early next cycle"

* hashpling (charles@hashpling.plus.com) has left

* Guest64284 has quit (Quit: http://www.mibbit.com ajax IRC Client)

<tristan> For today, are we ready to adjourn ?

<ltu> nothing more from me

<ssam2> nothing from me

<sstriker> +1

<juergbi> _o_

<tristan> We didnt cover this in release schedule, but petty detail, I'd like to also follow GNOME style release numbering

<tristan> even minor number = stable, odd minor number = devel

<persia> +1

<tristan> That's all

<tristan> Ok - thank you all for coming in such great numbers !

<tristan> Was a pleasure