IRC logs for #trustable for Thursday, 2018-06-28

*** willbarnard has joined #trustable07:45
*** weyfonk has joined #trustable07:50
willbarnardKinnison: if it addresses your concerns, could you approve !28?08:24
KinnisonCould you supply a URL rather than just an MR number?08:24
willbarnardhttps://gitlab.com/trustable/workflow/merge_requests/2808:25
* Kinnison has clicked a button08:27
* Kinnison does not take responsibility with this action08:27
Kinnison:-)08:27
willbarnardthx08:27
* Kinnison wishes Gitlab had a rubber-stamp button as well as a 'I reviewed and approve' button08:28
Kinnisonbecause even though I read the changes and they seemed to improve matters, I'm still not entirely sure about Gate, but am having difficulty wording08:29
willbarnardif you have further questions, then raise them here and we can try to address them08:30
KinnisonAs I say, I'm not sure about how to word my concerns yet08:30
paulsherwoodKinnison: there is a rubber-stamp button... it's the thumbs-up, thumbs-down09:02
Kinnisonpaulsherwood: I'd say that's more of a qualitative analysis09:02
* Kinnison guesses an "approve" without any indication of a review is a sufficient rubber stamp09:03
* Kinnison used to use r+ to mean "reviewed and approved positively" vs. rs+ to mean "rubber stamped, just do it" at a previous job09:03
paulsherwoodack09:03
paulsherwoodwell, for the current level of 'maturity' here, single approver still seems ok to me, but at some point in future i hope we get to a justification for two or more approvals09:04
* Kinnison notes that until and unless you have enough people tasked with reviewing changes, getting to that point is super-hard09:05
KinnisonFor Gitano, we still operate a one author plus one reviewer approach for all but the most scary of changes09:05
KinnisonEven though I nominally have three or four people who might review if asked09:05
paulsherwoodare you using mailing list for patch review there?09:08
paulsherwoodthe main disadvantage for me with the gitlab/github MR/PR approach is that the changes don't land in all subscribers' inbox by default :-)09:09
KinnisonWe are using a mailing list (gitano-dev) yes.09:09
KinnisonIt'd be hard to use anything else really :)09:09
* Kinnison still strongly prefers MLs for review but appreciates it puts a barrier in place which excludes a lot of people09:10
persiaExtracting status metrics and pretty graphs from mailing lists is also tricky.  There are tools that try (and even perform well enough to be useful), but with a number of false positives/negatives as email is not required to be machine readable.09:27
* Kinnison nods. Email is for humans09:27
persiaFrom curiosity, do you know of any automerge systems (e.g. for pre-merge testing) that work based on email?09:31
KinnisonThere used to be something used with bzr and mailing lists09:32
Kinnisoncombined with a PQM09:32
* Kinnison likes email based PQMs09:32
persiaPQM?09:32
persiapatch-queue-manager?09:32
KinnisonYep09:33
KinnisonThere was something which integrated with a PQM (not the one called PQM) which read the queue, ran tests, and reported results to the manager09:34
* Kinnison wishes he could remember its name09:34
KinnisonAt some point I'll just give up trying to remember, and then I'll remember it :-)09:35
* Kinnison doesn't do well with forced recollection09:35
persiaIf you happen to remember, please share.  Such a thing would be hugely useful for speculative analysis of potential changes for projects that use ML-based review (whether one's own projects or for speculative CI against dependency projects)09:42
*** willbarnard has quit IRC16:42
*** weyfonk has quit IRC17:11

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!