*** willbarnard has joined #trustable | 07:45 | |
*** weyfonk has joined #trustable | 07:50 | |
willbarnard | Kinnison: if it addresses your concerns, could you approve !28? | 08:24 |
---|---|---|
Kinnison | Could you supply a URL rather than just an MR number? | 08:24 |
willbarnard | https://gitlab.com/trustable/workflow/merge_requests/28 | 08:25 |
* Kinnison has clicked a button | 08:27 | |
* Kinnison does not take responsibility with this action | 08:27 | |
Kinnison | :-) | 08:27 |
willbarnard | thx | 08:27 |
* Kinnison wishes Gitlab had a rubber-stamp button as well as a 'I reviewed and approve' button | 08:28 | |
Kinnison | because even though I read the changes and they seemed to improve matters, I'm still not entirely sure about Gate, but am having difficulty wording | 08:29 |
willbarnard | if you have further questions, then raise them here and we can try to address them | 08:30 |
Kinnison | As I say, I'm not sure about how to word my concerns yet | 08:30 |
paulsherwood | Kinnison: there is a rubber-stamp button... it's the thumbs-up, thumbs-down | 09:02 |
Kinnison | paulsherwood: I'd say that's more of a qualitative analysis | 09:02 |
* Kinnison guesses an "approve" without any indication of a review is a sufficient rubber stamp | 09:03 | |
* Kinnison used to use r+ to mean "reviewed and approved positively" vs. rs+ to mean "rubber stamped, just do it" at a previous job | 09:03 | |
paulsherwood | ack | 09:03 |
paulsherwood | well, 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 approvals | 09:04 |
* Kinnison notes that until and unless you have enough people tasked with reviewing changes, getting to that point is super-hard | 09:05 | |
Kinnison | For Gitano, we still operate a one author plus one reviewer approach for all but the most scary of changes | 09:05 |
Kinnison | Even though I nominally have three or four people who might review if asked | 09:05 |
paulsherwood | are you using mailing list for patch review there? | 09:08 |
paulsherwood | the 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 |
Kinnison | We are using a mailing list (gitano-dev) yes. | 09:09 |
Kinnison | It'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 people | 09:10 | |
persia | Extracting 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 humans | 09:27 | |
persia | From curiosity, do you know of any automerge systems (e.g. for pre-merge testing) that work based on email? | 09:31 |
Kinnison | There used to be something used with bzr and mailing lists | 09:32 |
Kinnison | combined with a PQM | 09:32 |
* Kinnison likes email based PQMs | 09:32 | |
persia | PQM? | 09:32 |
persia | patch-queue-manager? | 09:32 |
Kinnison | Yep | 09:33 |
Kinnison | There was something which integrated with a PQM (not the one called PQM) which read the queue, ran tests, and reported results to the manager | 09:34 |
* Kinnison wishes he could remember its name | 09:34 | |
Kinnison | At 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 recollection | 09:35 | |
persia | If 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 IRC | 16:42 | |
*** weyfonk has quit IRC | 17:11 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!