15:02:25 <nils> #startmeeting modularity_wg
15:02:25 <zodbot> Meeting started Tue Dec  4 15:02:25 2018 UTC.
15:02:25 <zodbot> This meeting is logged and archived in a public location.
15:02:25 <zodbot> The chair is nils. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:25 <zodbot> The meeting name has been set to 'modularity_wg'
15:02:26 <nils> #meetingtopic Weekly Meeting of the Modularity Working Group
15:02:26 <nils> #chair dgilmore langdon sct
15:02:26 <zodbot> Current chairs: dgilmore langdon nils sct
15:02:31 <asamalik> .hello2
15:02:32 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
15:02:35 <nils> #topic Roll Call
15:02:39 <contyk> .hello psabata
15:02:39 <nils> .hello nphilipp
15:02:39 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:02:42 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
15:03:08 <langdon> .hello2
15:03:09 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
15:03:27 <nils> #topic Agenda
15:03:44 <nils> #info #108 How do we keep rawhide sane?
15:03:50 <nils> #info #112 Discussion: Module lifecycles
15:03:57 <nils> #info #114 Stream default changes & Fedora Changes
15:04:05 <nils> #info #115 Discussion: Stream branch ownership for packages & modules
15:04:13 <nils> and I believe we got a couple more
15:04:17 <nils> #chair contyk
15:04:17 <zodbot> Current chairs: contyk dgilmore langdon nils sct
15:04:20 <contyk> I have one more thing -- review of the naming guidelines
15:04:28 <nils> #info review of the naming guidelines
15:04:38 <nils> this doesn't have a ticket, right?
15:04:48 <contyk> it doesn't
15:04:50 <ignatenkobrain> .hello2
15:04:51 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:05:03 <nils> Anything else?
15:05:13 <contyk> nope
15:05:15 <asamalik> nothing else for me
15:05:18 <nils> good
15:05:28 <nils> #topic #108 How do we keep rawhide sane?
15:05:28 <nils> #link https://pagure.io/modularity/issue/108
15:05:37 <nils> #chair asamalik
15:05:37 <zodbot> Current chairs: asamalik contyk dgilmore langdon nils sct
15:06:12 <nils> Last week I thought we got this through, but apparently not quite. asamalik?
15:06:34 * contyk looks
15:06:48 <contyk> I thought this was resolved
15:07:19 <nils> Me too, but there was more commentary in the ticket and Adam wanted to have it on the agenda again...
15:07:27 <nils> #chair sct
15:07:27 <zodbot> Current chairs: asamalik contyk dgilmore langdon nils sct
15:07:30 <asamalik> That's the topic we wanted to discuss with sct
15:07:39 <nils> Hey sct :)
15:07:40 * asamalik waves at sct
15:07:40 <sct> .hello sct
15:07:41 <zodbot> sct: sct 'Stephen Tweedie' <sct@redhat.com>
15:07:46 * sct waves!
15:08:32 <contyk> is it? thought that was the next one
15:08:36 <contyk> maybe it's both
15:08:56 <asamalik> contyk: just this one as far as I know
15:08:57 <contyk> ah, no, it's this one
15:09:10 <contyk> sct: https://pagure.io/modularity/issue/108
15:09:26 <contyk> sct: it's how we handle defaults changing over time; dist upgrades, rawhide
15:09:59 <contyk> sct: you sounded like you wanted to discuss this some more
15:10:51 <sct> Well, I can see various ways to go... is this an open-ended question or do we have a specific suggestion atm?
15:11:18 <asamalik> sct: there is a specific suggestion there
15:11:24 <contyk> sct: last week the group agreed to the proposal in the ticket, i.e. ...
15:11:28 <contyk> asamalik will summarize it
15:11:31 <contyk> ;)
15:11:34 <asamalik> sure
15:12:08 <asamalik> when you install a module, you have two options: the default, or a specific stream
15:12:16 <asamalik> "dnf module install nodejs" gives you the default
15:12:26 <asamalik> "dnf module install nodejs:8" gives you a specific stream
15:12:58 <asamalik> your choice will be remembered and respected during a distro upgrade — by either keeping you on the default (and potentially changing a stream) or keeping you on the specific stream you chose
15:13:32 <sct> asamalik: That makes sense to me.  But wasn't there also some thought that we might do this automatically for rawhide updates?
15:13:36 <contyk> basically it remember whether you chose the default or something specific, rather than always remembering a specific stream
15:13:42 <asamalik> that works with both sets of expectations: traditional fedora — where a distro upgrade gives you new versions, and modularity — where your choice of a stream is respected and remembered
15:14:04 <contyk> and yes, I think saying it applies only on dist upgrades is misleading
15:14:13 <asamalik> sct: let me make a small correction — technically this happens with every update, by policy only during major upgrades
15:14:13 <nils> it just applies
15:14:18 <contyk> it applies when the defaults change; which happens in rawhide and, in stable, only on dist upgrades
15:14:33 <asamalik> sct: rawhide can change defaults basically anytime, the same way as it can change major package versions
15:14:54 <asamalik> EOF
15:15:18 <sct> asamalik: OK.  We have a general set of issues about changing the module metadata mid-release
15:15:22 <nils> yeah, "when defaults change" is the salient thing
15:15:26 <sct> because we don't know exactly which one is installed;
15:15:29 <sct> but in this specific case
15:15:48 <sct> we *do* always know which stream is enabled, and we can tell when that changes
15:15:59 <sct> (can tell when the default changes)
15:16:13 <asamalik> sct: the proposal makes a suggestion that dnf either remembers "the default" or "a specific stream". Right now it can only remember "a specific stream"
15:16:22 <langdon> but the important part is that the user chose this enabled stream vs just picked up the default
15:16:34 <asamalik> ... for all installed / enabled modules, that is
15:16:36 <nils> asamalik, could it also remember -nothing- meaning default?
15:16:41 <sct> asamalik: I don't think that works
15:16:48 <contyk> ...so unless we change the configs/database, we will not remember which specific stream is enabled
15:17:04 <sct> asamalik: I think we need to know which exact stream is enabled, and *also* whether it is "locked" or able to follow moving defaults
15:17:32 <sct> asamalik: because we might need different (distro-sync) semantics for an update when a stream changes, from when we're just updating on the same stream.
15:17:39 <contyk> sct: can you give an example why it would be important instead of dnf update just moving you to the new stream?
15:17:42 <nils> sct, do we need to remember the specific stream if unlocked, i.e. it's just what follows from the default being set elsewhere?
15:17:47 * contyk nods
15:18:04 <asamalik> sct: fair and a good point — although that might be an implementation detail, not a requirement if I'm not missing something
15:18:12 <sct> contyk: The obvious one would be if we have a newer stream that for some reason has a lower NVR of some component rpm
15:18:26 <contyk> sct: I don't think you need to know what stream you had enabled before the defaults change but you might need to run distro-sync to update properly, yes
15:18:29 <sct> contyk: which shouldn't be common, but it is possible in theory, and supported by module semantics
15:18:50 <sct> and it would require the "dnf update" to be a downgrade in the specific case of switching stream.
15:19:17 <langdon> from a user perspective, wouldn't i want to be able to look to see what stream I am on? even if it was default? in case I want to make it stick when I hear a new stream will become default?
15:19:19 <sct> contyk: You don't need to know the old stream, right; but you do need to be able to notice that the new stream is different, which is nearly the same thing.
15:20:33 <sct> langdon: +1, it would make sense to be able to track the current stream separately from the repodata default for that purpose
15:20:33 <contyk> okay, so let's say we remember both the active stream and whether we're following the defaults or not
15:20:46 <contyk> what would you suggest "dnf update" should do?
15:21:52 <asamalik> langdon: +1, although we'd need to make sure the following two scenarios are displayed correctly 1) "you have a default which is stream 8" 2) "you have the stream 8 which is btw a default"
15:22:00 <langdon> contyk: who are you asking?`
15:22:06 <contyk> anyone
15:22:15 <contyk> langdon: mostly sct and you, though
15:22:24 <langdon> oh.. i agree w/ the ticket.. if you are explicit, honor, else, follow default
15:22:26 <langdon> s
15:22:27 <sct> Mostly update is the same as today;
15:22:28 <sct> but
15:22:35 <asamalik> contyk: I believe that "dnf update" should give you the "latest versions of packages in your selected stream" — potentially downgrading packages
15:22:44 <nils> asamalik, +1
15:23:08 <contyk> asamalik: that implies running distro-sync
15:23:13 <sct> if we are following the default, and the current default is different from our current enabled stream, then instead of update, we treat it as a stream switch and distro-sync to the new NVRs for that module's contents only.
15:23:29 <langdon> right
15:23:44 <sct> (With the usual provision that it's not an exact NEVRA, because we still need to honour hotfixes even in this case, which is potentially nasty.)
15:23:51 <asamalik> contyk: yes — that's my suggestion at least and that's what I'd expect, although I recognize it's a change in behavior some users might expect
15:23:58 <contyk> yes, that makes sense; just unsure whether we and the dnf team would be okay with running distro-sync as part ot the update operation
15:24:21 <asamalik> although some concepts introduced by Modularity make "my" proposal make sense
15:24:38 <asamalik> sct: +1
15:24:49 <asamalik> langdon: +1
15:24:54 <contyk> so "dnf update" would tell you "you're switching streams, nodejs:8->nodejs:10", for instance, and run distro-sync on that package set
15:24:57 <contyk> correct?
15:25:04 <asamalik> contyk: +1
15:25:22 <nils> contyk, +1
15:25:26 <asamalik> correct — that's what I'd expect
15:26:02 <contyk> hotfixes included as update candidates, of course
15:26:05 <contyk> sct, langdon: ?
15:26:08 <sct> +1
15:26:21 <asamalik> in other words, update is always an update, except when switching a stream. In that case, it's a distro-sync for the module's package set.
15:26:27 <langdon> contyk: im +1 but didn't understand your last statement
15:26:49 <asamalik> ... plus an update for the rest
15:27:03 <contyk> langdon: we don't want to sync to the latest NEVRAs within the stream only, we want to install or keep hotfixes if their NEVRA is higher
15:27:31 <nils> Do we? A hotfix might be applicable only in the context of its stream.
15:27:32 * langdon thinks
15:28:03 <asamalik> nils: I thought a hotfix doesn't have such context, and overrides whatever has a lower NEVR
15:28:04 <contyk> nils: yes, but you can't reasonably tell and if the NEVRA is higher, the following dnf update would update you to it anyway
15:28:20 <langdon> i agree with nils.. kinda.. if an rpm is in "not a stream" it should update any lower NEVRA available..
15:28:21 <nils> ahh, gotcha
15:28:44 <langdon> if the hotfix is only for a stream.. it belongs in the stream virt repo
15:28:56 <contyk> langdon: you don't have such information for hotfixes
15:29:03 <nils> langdon, ...except if it's from platform (but we imply a stream there, right?)
15:29:04 <contyk> hotfixes are simple RPMs
15:29:42 <langdon> ohh in the very specific language, yes.. in the more general, "hot fix" terminology, it could be either
15:29:49 <asamalik> hotfixes are almost like standalone RPMs with the exception they can win over modular RPMs with NEVRA comparison, right?
15:30:02 <asamalik> *with -> in
15:30:04 <contyk> yes
15:30:15 <langdon> any rpm that is "not in a stream" will win over the stream version.. won't it?
15:30:26 <contyk> langdon: no, the other way around
15:30:46 <asamalik> are we considering hotfixes to be in scope here because of the distro-sync?
15:30:48 <langdon> wait .. what?
15:31:07 <asamalik> or is there any other reason I'm missing?
15:31:08 <contyk> langdon: modules override non-modular content; non-modular content (and non-enabled streams) are completely masked
15:31:26 <contyk> the only exception are hotfixes, which are considered as candidates and subject to the standard NEVRA comparison
15:31:44 <sct> asamalik: Right
15:32:02 <langdon> so how does dnf know that this bare-rpm is a hotfix vs a "regular" bare-rpm?
15:32:21 <contyk> langdon: repo flags, installing from the fs directly...
15:32:26 <sct> langdon: It's a flag on the repo configuration
15:33:02 <langdon> ahh ok.. i see.. i think this is why i have been confused by this bit a bunch of times.. i didn't know hotfix rpms were actually special
15:33:25 <asamalik> #action asamalik documents how updates work, including standalone RPMs, modular RPMs, and hotfixes
15:33:26 <asamalik> :)
15:34:01 <contyk> okay, so that cleared, I think we have an agreement
15:34:23 <nils> I think it's worthwhile to stress this point in docs. For instance if you pull testing updates directly from koji, and install them they will be considered hotfixes (AIUI) and change the update semantics accordingly.
15:34:25 <contyk> "update" informs you about streams being switched and runs distro-sync on that modular package set, respecting hotfixes
15:34:38 <asamalik> nils: agree, see the action above
15:34:47 <langdon> do we want to have a "group answer" for why we don't like a "lock flag" per the ticket?
15:35:04 <asamalik> contyk: +1
15:35:05 <nils> langdon, DYM "lock command"?
15:35:30 <langdon> neal's example is a "--lock" .. so.. no, i mean flag
15:35:35 <langdon> but either way
15:35:48 <langdon> ohh.. he has both
15:35:48 * contyk points langdon to the last week's log
15:36:00 <nils> Because AIUI we implicitly have a "lock flag" by being able to remember if a module is supposed to follow "the default of the day"
15:36:05 <langdon> oh .. was that in the beginning of the meeting i missed?
15:36:55 <contyk> I don't remember when exactly we talked about it
15:36:57 <langdon> i just don't like it for two reasons a) "lock", i think, means "nothing changes" like pinning today.. which is not how modules work b) it is extra "typing" / semantics that we don't need
15:37:38 <asamalik> langdon: sorry I'm confused, we're not proposing anything like that at the moment
15:38:01 <langdon> asamalik: yeah.. but we don't have an answer to "why" in the ticket aside from you saying it is yucky :)
15:38:04 <asamalik> it's "dnf module install nodejs" for a default, and "dnf install nodejs:8" for a specific stream with 'the locking'
15:38:06 <nils> langdon, ah gotcha -- yeah I concur we don't want that users have to use this command. It could exist to change from "follow default" to "stay on this stream" later but isn't really relevant in this convo IMO.
15:38:07 <contyk> --lock only makes sense in combination with no stream being specified, kinda like "expand nodejs and lock that instead of following the default", but it was deemed unnecessary, confusing and pointless
15:38:31 <nils> Ahh. *rubs eyes*
15:38:49 <asamalik> langdon: ah now I understand! let me respond there
15:39:12 <asamalik> contyk: +1
15:39:14 <asamalik> that
15:39:31 <nils> langdon, neal also mentioned "dnf module lock ..." -- https://pagure.io/modularity/issue/108#comment-543047
15:39:32 <asamalik> + the term "lock" is confusing as per what langdon said
15:39:47 <langdon> yeah
15:40:02 <asamalik> so let's not do the lock thing, and just respond why not
15:40:25 <asamalik> also, 40 mins in, do we want to move on?
15:40:46 <nils> as far as I'm concerned, sure
15:41:05 <asamalik> do we want to do an #agreed about: contyk> "update" informs you about streams being switched and runs distro-sync on that modular package set, respecting hotfixes
15:41:06 <asamalik> ?
15:41:24 <nils> sure
15:41:26 <nils> +1
15:41:30 <asamalik> as a correction of that decision from last time
15:41:36 <contyk> proposed #agreed "dnf update" should inform users about streams being switched and perform distro-sync on the affected modular package set, taking hotfixes into consideration
15:41:38 <nils> an amendment
15:41:38 <asamalik> or making it more specific
15:41:53 <asamalik> nils: that's the word!
15:42:18 <asamalik> contyk: do you want to explicitly add that we're tweaking the decision from last time?
15:42:20 <nils> +1 on the amendment
15:42:29 <nils> it's not tweaking, but clarifying
15:42:37 <contyk> asamalik: I think that's given
15:42:46 <contyk> or that
15:42:50 <asamalik> contyk: ok fair, would you be +1 or +0 still?
15:43:16 <asamalik> although I might be just ratholing right now :)
15:43:23 <contyk> asamalik: no point in voting again :)
15:43:26 <asamalik> +1 to the proposed #agreed
15:43:31 <nils> yup
15:43:32 <asamalik> contyk: right :)
15:43:34 <contyk> #agreed "dnf update" should inform users about streams being switched and perform distro-sync on the affected modular package set, taking hotfixes into consideration
15:43:40 <asamalik> cool
15:43:40 <langdon> i am terrible at this but isn't it "effected" ?
15:43:45 <asamalik> nils: can you skip a topic please?
15:43:50 <nils> langdon, no
15:43:59 <contyk> langdon: nope
15:44:03 <langdon> cool... that's one of those ones i can never remember
15:44:12 <asamalik> nils: there is no way we can finish the lifecycles, but we can pass the third one about fedora changes
15:44:18 <nils> ok
15:44:23 <asamalik> nils++
15:44:27 <nils> skipping, wait a sec
15:44:49 <nils> #topic #114 Stream default changes & Fedora Changes
15:44:49 <nils> #link https://pagure.io/modularity/issue/114
15:45:23 <contyk> so there were two proposals in the ticket
15:45:39 <langdon> the right one and the wrong one!??!??!
15:45:42 <asamalik> yes
15:45:46 <contyk> I'm leaning towards supporting that of asamalik
15:45:50 <asamalik> langdon: obviusly!
15:45:54 <contyk> which is more restrictive than ignatenkobrain's but safer
15:46:15 * asamalik also supports his own proposal
15:46:31 <asamalik> we can always relax it later when we're confident everything works smoothly
15:46:47 <nils> contyk, in what way is it more restrictive?
15:47:09 <langdon> no mid-cycle modules replacing ursine rpms
15:47:16 <asamalik> langdon: +1
15:47:17 <contyk> nils: ignatenkobrain proposes we could replace ursine packages with modular and make those modules the default in stable
15:47:32 <asamalik> because right now it's the same as removing packages from the buildroot
15:47:36 <contyk> nils: asamalik proposes we can replace them with modular but only add the defaults in the future release
15:47:36 <asamalik> mid-release
15:47:38 <nils> ahh okay, so that's a change from how I've understood we wanted it originally
15:47:52 <asamalik> cool!
15:47:55 <nils> asamalik, because UM isn't there yet?
15:48:00 <asamalik> nils: right
15:48:05 <nils> 👍
15:48:20 <asamalik> any other questions or vote?
15:48:41 <nils> no further questions from me
15:48:43 <langdon> im a little confused now
15:48:47 <contyk> +1 to asamalik's proposal
15:48:53 <nils> langdon, ?
15:49:23 <langdon> "asamalik proposes we can replace them with modular but only add the defaults in the future release" < where does it say this? i thought it said you can't replace ursine with a module mid-cycle.. but this remark says something else
15:49:58 <asamalik> langdon: "No default stream changes mid-release are permitted."
15:50:14 <nils> ...10 minutes...
15:50:18 <asamalik> which includes moving an ursine RPM to a module and making a default
15:50:24 <langdon> but you are still removing the rpms from the build root in that scenario
15:50:50 <langdon> what does the default part have to do with it?? :) ... you are still removing an ursine rpm, no?
15:50:52 <contyk> you don't drop packages from stable
15:51:02 <langdon> the default part would just make it easier on users
15:51:03 <contyk> the ursine packages are going to be there until the release goes EOL
15:51:04 <asamalik> you can always make the module, but you need to wait with removing the ursine package and setting the default for the upcoming release
15:51:36 <contyk> you can make modules with the same content and optionally enable them
15:51:55 <langdon> ok... that makes sense.. but i don't think the proposal says you can introduce a new morule mid-cylce
15:52:01 <contyk> if you make them the default, without Ursa Major, the RPM in the buildroot will differ from the one you have available at runtime
15:52:18 <asamalik> langdon: it does: "Introducing a new default stream not replacing any existing default stream or a traditional package is not considered a change. That means it can be done."
15:52:39 <langdon> how about "introducing a regular old stream"? :)
15:53:00 <asamalik> langdon: you mean introducing a non-default stream?
15:53:07 <langdon> ie... introducing a "new stream" that is not default
15:53:15 <langdon> yeah.. it doesn't say you can do that
15:53:16 <asamalik> that's completely out of scope of this
15:53:25 <asamalik> that doesn't introduce any changes
15:53:31 <asamalik> right?
15:53:40 <contyk> correct, that's just adding new content
15:53:43 <langdon> "Introducing a new default stream not replacing any existing default stream or a traditional package is not considered a change. That means it can be done." could be "Introducing a new stream or module not replacing any existing default stream or a traditional package is not considered a change. That means it can be done.
15:54:01 <langdon> but the wording implies that you can't do it
15:54:05 <langdon> for me at least
15:54:17 <nils> yeah, mentioning streams for the seems kind of roundabout
15:54:45 <nils> if we consider adding a default stream on top of ursine RPMs "changing the default stream"
15:55:29 <asamalik> langdon: the issue is about changing default streams
15:55:41 <asamalik> langdon: anything that is not changing default streams is out of scope
15:56:25 <langdon> ok.. if everyone else agrees with you, i am fine.. i just think your choice of wording implies that you can't introduce new modules or streams..
15:56:38 <nils> asamalik, I think what langdon is getting at is that introducing a default stream on top of ursine content isn't permissible and how we phrase this is too complicated
15:59:01 <nils> It's not obvious that only adding a default stream for content that isn't available as ursine packages is ok. Did I get you right, langdon?
15:59:08 <asamalik> langdon: how is that related to defaults?
15:59:20 * asamalik doesn't want to overcomplicate the description
15:59:23 * asamalik hopes he sounds polite
15:59:30 <langdon> :P
16:00:07 <langdon> let's let it be.. and when it gets added to the full doc.. ill look at it again .. and see if i still think it needs a change
16:00:20 <nils> ok
16:00:30 <nils> have we #agreed on anything yet, I can't remember...
16:00:32 <asamalik> nils: I think that's exactly what it says in the last point, but we can definitely reword it
16:00:43 <contyk> asamalik: could you do a proposed #agreed?
16:00:54 <asamalik> contyk: ok
16:01:31 <nils> asamalik, I think the implications might not be obvious to everybody, but let's not drag this on further and fine tune later
16:02:07 <asamalik> proposed #agreed We'll handle default stream changes and the respective Fedora Changes as described in this issue description: https://pagure.io/modularity/issue/114
16:02:36 <contyk> that issue can change ;)
16:02:47 <langdon> it will be getting moved to https://pagure.io/modularity/working-documents/blob/master/f/lifecycles-upgrades-ownership/defaults-and-fedora-changes.md though, right?
16:02:50 <asamalik> contyk: ha
16:03:08 <asamalik> ok let me copy/paste the four points
16:03:29 <nils> asamalik, maybe copy/paste them into one comment and link that one directly?
16:03:47 <nils> otherwise, the #agreed might get very bulky...
16:03:57 <asamalik> proposed #agreed 1) Module stream defaults should be only changed in an upcoming Fedora release 2) Changes of stream defaults should be communicated by a Fedora Change based on the change's significance and its maintainer's best judgement. 3) No default stream changes mid-release are permitted. 4) Introducing a new default stream not replacing any existing default stream or a traditional package is not considered a
16:03:57 <asamalik> change. That means it can be done.
16:04:03 <asamalik> :/
16:04:51 <nils> +1 even if bulky :)
16:05:20 <asamalik> langdon: I'll put it right in the docs
16:05:28 <langdon> +1
16:05:45 <contyk> +1
16:06:07 <asamalik> #agreed 1) Module stream defaults should be only changed in an upcoming Fedora release 2) Changes of stream defaults should be communicated by a Fedora Change based on the change's significance and its maintainer's best judgement. 3) No default stream changes mid-release are permitted. 4) Introducing a new default stream not replacing any existing default stream or a traditional package is not considered a change.
16:06:07 <asamalik> That means it can be done.
16:06:12 <contyk> you can split it into two #agreed points to log it
16:06:17 <asamalik> ha, well at least all the info fits
16:06:27 <contyk> #agreed ^ That means it can be done.
16:06:28 <contyk> done
16:06:34 <contyk> I need to go afk
16:06:36 <asamalik> contyk++
16:06:44 <asamalik> contyk: have a safe flight!
16:06:59 <contyk> heh, thanks
16:07:02 <asamalik> #action asamalik documents the new policy
16:07:24 <nils> contyk, safe travels!
16:07:39 <nils> good, considering we're past time, let's postpone the rest?
16:07:46 <contyk> yeah
16:08:03 <asamalik> I could do both, although I'd prefer postponing
16:08:32 <nils> I've postponed a call I had on the hour to :15 :)
16:09:04 <nils> Alright. Thanks everybody!
16:09:04 * asamalik waits for waving
16:09:08 <nils> #endmeeting