[13:51] <niemeyer> TheMue: How did the review look? Good stuff?
[13:52] <TheMue> niemeyer: yip, the changes are back in (after i had another special task: check the translation of the press release to maas) ;)
[14:01] <niemeyer> TheMue: What's coming next?
[14:01] <niemeyer> TheMue: Acting as a translator too?  Nice. :)
[14:02] <TheMue> niemeyer: if it's ok for you now i'll submit it and then realize the next watches
[14:02] <TheMue> niemeyer: as long as you don't have something more urgent for me
[14:04] <TheMue> niemeyer: do we have a kind of roadmap in which order the missing parts shall be ported?
[14:05] <niemeyer> TheMue: Not at this time.. we have to do all of them, and nobody else is blocked on missing pieces of the state, so you're free to pick the next slice
[14:05] <niemeyer> TheMue: That said, given we've just entered watches and have them fresh in our minds, sounds like a good choice indeed
[14:06] <niemeyer> TheMue: I'll have a last look right away
[14:06] <TheMue> niemeyer: Fine, so I would continue with those.
[14:17] <niemeyer> TheMue: Just for the record:
[14:17] <niemeyer> """
[14:17] <niemeyer> Done. Difficult situation would be if in case of an internal watcher error
[14:17] <niemeyer> Dying() returns an error too. Haven't been able to discaver that in the control
[14:17] <niemeyer> flow.
[14:17] <niemeyer> """
[14:17] <niemeyer> TheMue: It's fine to give precedence to one of the errors in that case
[14:17] <niemeyer> TheMue: You've picked the right end of it as well, IMO.. the underlying error is likely of higher precedence if both exist
[14:26] <TheMue> niemeyer: That has been my thought too. And I think a panic would be too much while some kind of crippled error mix of both won't help too.
[14:26] <niemeyer> Right
[14:28] <niemeyer> TheMue: You got a plain LGTM
[14:28] <TheMue> niemeyer: great, thx
[14:28] <niemeyer> TheMue: Turned out very well.. love the new watch infra
[14:30] <TheMue> niemeyer: me too, one kind of tasks which go can handle very well
[15:03] <robbiew> of course fwereade leaves the room at our 1:1 time
[15:03] <robbiew> lol
[15:04] <niemeyer> :-)
[15:12] <niemeyer> Lunch time.. biab
[15:34] <flacoste> SpamapS: when are you planning on next uploading to the archive?
[15:34] <flacoste> SpamapS: the current archive version doesn't have the constraints support
[15:34] <flacoste> SpamapS: not a big deal, but just would like to know your plans
[15:44] <SpamapS> flacoste: when subordinates lands
[15:44] <flacoste> SpamapS: what's the ETA for that?
[15:44] <SpamapS> bcsaller: how goes it btw?
[15:45] <SpamapS> flacoste: I've seen brief flurries of review/fix/review cycles so it must be close.
[16:39] <fwereade> gn all (actually, happy weekends all, really, holiday tomorrow)
[16:44] <TheMue> fwereade: yip, have a nice long weekend too
[16:48] <niemeyer> fwereade: Have a good one!
[18:51] <hazmat> jimbaker, after your done merging the rel-id work, would you mind having a look at this txzk branch http://codereview.appspot.com/5976074/
[19:35] <jimbaker> hazmat, will do
[19:43] <hazmat> jimbaker, thanks
[21:05] <niemeyer> jimbaker, hazmat: "Use the new hook command, relation-ids [RELATION_NAME], which takes an
[21:05] <niemeyer> optional relation name (otherwise implies all)"
[21:05] <niemeyer> jimbaker, hazmat Otherwise implies all?
[21:05] <hazmat> niemeyer, yes
[21:05] <hazmat> niemeyer, all relation ids are returned if no name is specified
[21:05] <niemeyer> hazmat: The agreement is that it should imply the current relation name
[21:06] <hazmat> niemeyer, if one exists
[21:06] <hazmat> it does
[21:06] <hazmat> but in the case of a non rel hook context, it won't
[21:06] <niemeyer> hazmat: Yes, if you doesn't exist it should break and say "give me a relation name"..
[21:06] <niemeyer> hazmat: Otherwise the command has a completely different behavior depending on context
[21:07] <jimbaker> niemeyer, hazmat, the actual behavior is to return all the relation ids if no relation name is specified, regardless of context
[21:07] <niemeyer> jimbaker: That's not what we agreed
[21:07] <jimbaker> whether relational or not
[21:07] <hazmat> jimbaker, doesn't it default to an env var?
[21:07] <jimbaker> niemeyer, i can certainly change it
[21:08] <jimbaker> hazmat, it was originally doing that, but that caused the inconsistency
[21:08] <jimbaker> instead we can have it raise an error as niemeyer suggests
[21:09] <hazmat> sounds good
[21:09] <jimbaker> hazmat, cool
[21:10] <niemeyer> jimbaker: """
[21:10] <niemeyer> 	  4 This proposal adds a new relation hook command to enumerate the
[21:10] <niemeyer>   5 relations a service participates in::
[21:10] <niemeyer>   6
[21:10] <niemeyer>   7    relation-ids [RELATION_NAME]
[21:10] <niemeyer>   8
[21:10] <niemeyer>   9 Hooks that are not relational hooks must specify the relation name as
[21:10] <niemeyer>  10 an argument; otherwise an error is raised stating "Relation name must
[21:10] <niemeyer>  11 be specified". For relational hooks, the corresponding relation name
[21:10] <niemeyer>  12 is the default.
[21:10] <niemeyer> """
[21:11] <jimbaker> niemeyer, thanks for pointing that out
[21:11] <niemeyer> jimbaker: I'm not reviewing the code going into the Python implementation.. if you don't pay attention to the specification, the point of we agreeing on it is moot
[21:13] <jimbaker> niemeyer, thanks, this was very helpful