| niemeyer | TheMue: How did the review look? Good stuff? | 13:51 |
|---|---|---|
| TheMue | niemeyer: yip, the changes are back in (after i had another special task: check the translation of the press release to maas) ;) | 13:52 |
| niemeyer | TheMue: What's coming next? | 14:01 |
| niemeyer | TheMue: Acting as a translator too? Nice. :) | 14:01 |
| 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:02 |
| TheMue | niemeyer: do we have a kind of roadmap in which order the missing parts shall be ported? | 14:04 |
| 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:05 |
| niemeyer | TheMue: I'll have a last look right away | 14:06 |
| TheMue | niemeyer: Fine, so I would continue with those. | 14:06 |
| 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:17 |
| 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:26 |
| 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:28 |
| TheMue | niemeyer: me too, one kind of tasks which go can handle very well | 14:30 |
| robbiew | of course fwereade leaves the room at our 1:1 time | 15:03 |
| robbiew | lol | 15:03 |
| niemeyer | :-) | 15:04 |
| niemeyer | Lunch time.. biab | 15:12 |
| 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:34 |
| SpamapS | flacoste: when subordinates lands | 15:44 |
| flacoste | SpamapS: what's the ETA for that? | 15:44 |
| SpamapS | bcsaller: how goes it btw? | 15:44 |
| SpamapS | flacoste: I've seen brief flurries of review/fix/review cycles so it must be close. | 15:45 |
| === hazmat is now known as kapilt | ||
| fwereade | gn all (actually, happy weekends all, really, holiday tomorrow) | 16:39 |
| TheMue | fwereade: yip, have a nice long weekend too | 16:44 |
| niemeyer | fwereade: Have a good one! | 16:48 |
| === kapilt is now known as hazmat | ||
| 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/ | 18:51 |
| jimbaker | hazmat, will do | 19:35 |
| hazmat | jimbaker, thanks | 19:43 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| hazmat | sounds good | 21:09 |
| jimbaker | hazmat, cool | 21:09 |
| 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:10 |
| 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:11 |
| jimbaker | niemeyer, thanks, this was very helpful | 21:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!