19:02:42 #startmeeting infra 19:02:43 Meeting started Tue Aug 19 19:02:42 2014 UTC and is due to finish in 60 minutes. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:02:46 The meeting name has been set to 'infra' 19:02:57 #link agenda https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:03:00 #link actions from last meeting: http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-08-12-19.02.html 19:03:12 #topic Actions from last meeting 19:03:16 o/ 19:03:18 o/ 19:03:19 o/ 19:03:19 o/ 19:03:19 o/ 19:03:26 o/ 19:03:28 o/ 19:03:38 hey-o 19:03:46 jeblair Publish python-jenkins 0.3.3 (last release without pbr) tarball to pypi 19:03:49 o/ 19:03:50 i did not do that 19:03:52 o/ 19:03:59 #action jeblair Publish python-jenkins 0.3.3 (last release without pbr) tarball to pypi 19:04:09 #topic Priority Specs (jeblair) 19:04:38 hey, so what with the fact that we're constantly swamped with reviews.... 19:04:44 we should review those 19:04:54 some projects have taken to highlighting changes that are a priority 19:05:04 and i thought maybe a good first step for that would be specs 19:05:24 wholeheartedly agree 19:05:38 ++ 19:05:40 so these are some specs that are really strategic for what we want to do this cycle (and probably next too :) 19:06:11 #link priority spec: https://review.openstack.org/#/c/100363/ 19:06:11 #link priority spec: https://review.openstack.org/#/c/99990/ 19:06:11 #link priority spec: https://review.openstack.org/#/c/110730/ 19:06:11 #link priority spec: https://review.openstack.org/#/c/110793/ 19:06:24 so if you have to pick some, those would be a good place to start 19:06:56 and i think maybe once we have some more specs approved, we might be able to prioritize the reviews that implement those 19:07:18 sounds like a fantastic plan 19:07:26 i don't know how formal we want to be about this, but i'm guessing that at least nominating these and communicating will probably help us a lot 19:07:39 a good start 19:07:41 yup 19:08:03 part of the problem with review backlog is lack of explicit prioritization. i hope this helps as much as i think it will 19:08:56 so anyway, if i've missed something feel free to contact me and i'll consider it. but i also want to keep the count fairly small and manageable 19:09:03 * krtaylor imagines a weighted review assignment to produce a prioritized list 19:09:50 krtaylor: that would be great; we've imagined that for a few years but need a feature in gerrit to store the weight/priority/whatever 19:10:14 krtaylor: maybe if the ci report plugin works out, that could be the next step 19:10:28 ++ 19:10:43 #topic email for gerrit third party ci accounts status (anteaya) 19:10:50 hello 19:10:51 but add to that wishlist feature, transitive weighting (association with a spec grants similar priority value) 19:11:17 so we used to require new gerrit accounts include the email for the gerrit account in the request 19:11:29 we have now changed that requirement 19:11:33 #link http://ci.openstack.org/third_party.html#requirements 19:11:51 and now require third party gerrit ci accounts to have a wikipage with contact info on it 19:11:55 \o/ 19:11:59 so the question is, how do we transition? 19:12:30 anteaya: maybe you mean http://ci.openstack.org/third_party.html#requesting-a-service-account ? 19:12:37 i think the higher-order question which has been raised is first, do we transition (or keep contact info in both places) 19:12:40 likely I do 19:12:56 so, i was ambivalent about this, until on friday when i disabled 4 accounts 19:13:09 how do you feel now, jeblair? 19:13:18 i wanted to send them mail, so i used the info in gerrit to get their addresses to cc them 19:13:24 i would not have clicked through to the wiki to do that 19:13:34 and, only about 30 have created wiki pages so far 19:13:41 krtaylor: wow that's a lot :) 19:13:47 (heh, "only about 30") 19:13:57 ya I am partial to having the info in gerrit too 19:14:07 hehheh, well, I guess its a matter of how you look at it :) 19:14:13 so i definitely still want them in the wiki, because i think all that info should be easily available for people wanting to learn about a system 19:14:19 having the email in gerrit means that mulitple accounts need separate email addresses 19:14:29 while i like having that info in gerrit, there are two complications which we've been living with so far but are pretty inconvenient 19:14:34 right, that's one 19:14:41 it's hard to explain to people 19:14:57 the need for separate emails is hard to explain? 19:15:03 so they get it wrong and we iterate over new account requests several times 19:15:07 but i think that if we expect that when we perform administrative actions on those accounts that we cc them, then we should keep them in gerrit 19:15:24 if we don't want to expect that, then i'm okay dropping them :) 19:15:25 fungi: anteaya: what was the other? 19:15:33 I am familiar with the email dances that have happened 19:15:33 surprisingly, yes. also because they often don't follow instructions and create an account or two through lp openid first with the same address 19:15:43 we need to be able to email them efficiently 19:15:46 second annoyance is that they can't change it. they have to ask us to change it 19:16:04 fungi: gotcha 19:16:17 fungi: they don't follow instructions - describes newcomers to this group very well 19:16:38 so the issue about having multiple accounts with the same address is mostly related to 'duplicate' lp accounts? 19:16:41 so i think if we do keep it in as a requirement, we need some better way of explaining it such that they're more likely to get it right the first time, and we need to also drive home that they should do everything in their power to not change what that address is 19:16:46 rather than multiple ci systems operated by the same people? 19:16:50 and them not following instructions and what to do about it deserves its own agenda item, in my mind 19:17:03 since it compounds so many other actions 19:17:20 well, depends on what you count as "duplicate" because also sometimes they try to provide their personal e-mail address as contact info even though they already are a reviewer in gerrit with an account associated with that address 19:18:13 and basically these don't come to light until we try to add the account and gerrit barfs 19:18:44 maybe explicit instructions explaining how to check that the address is not already in gerrit first before requesting the account? 19:19:02 do you think they would follow those instructions? 19:19:30 creating better instructions tends to result in just different questions in channel or them falling down in different places 19:19:48 the folks that would follow the new instructions also already follow the old ones 19:20:01 what if we had a third-party-ci-announce list, and asked all 3p operators to subscribe to it, and sent administrative action notifications there 19:20:07 i try not to assume anything about what anyone will actually do, just hope we can provide them with the greatest chance of getting it right the first time, understanding that english is often not their first language so reading english instructions may be hit-and-miss 19:20:13 we can try 19:20:28 I know that others want this back and forth out of their mind space 19:20:36 and I can't tell you how frustrated it makes me 19:20:40 jeblair: thats a good idea 19:20:45 I want to cry sometimes I get so tired 19:20:48 jeblair: or just -infra with a subject? 19:20:50 well, we could direct them to the third-party meetings to get started too 19:21:16 krtaylor: that redirect usually happens in response to an email 19:21:20 my personal pov is that i'm not particularly concerned if a 3p operator gets the message that their system has been disabled, but i want to give them a reasonable chance of getting it :) 19:21:34 which is why i did direct cc's on friday 19:21:39 i definitely appreciate how the third-party ci operator community is starting to come together and provide examples/mentoring to one another. any way we can facilitate increases and improvements in that behavior means less work for infra in the long term 19:21:52 fungi: yes 19:21:56 me too 19:22:15 but a dedicated announce list that is easy to follow should get a fairly similar result, without needing email addresses in gerrit (and it makes it easier for us too) 19:22:29 i think that's a great idea 19:22:31 we are brainstorming how to best police ourselves 19:22:31 let's try 19:22:41 at least it will be different 19:23:04 clarkb: and to your point about -infra, that's kind of anticipating another thing i put on the agenda 19:23:13 krtaylor: yes we are getting to a better place 19:23:14 I like the maillist idea too, or a way to email blast everyone on the gerrit service group 19:23:17 * wenlock wonders why requesting account isn't a commit request like everything else 19:23:29 " separate mailing list for third-party ci account requests (jeblair) " 19:23:34 wenlock: oh these folks couldn't get that at all 19:23:41 any way to filter requests up front with a lookup for some of these known cases? 19:23:41 wenlock: because we'd have to give a bot admin access :( 19:23:47 wenlock: have you read some of the interactions? 19:23:48 make a form that submits the commit request? 19:24:00 what about a simple web form, which could do things like the duplicate check before accepting the submission? 19:24:01 jinx 19:24:31 well actually if I had more help responding to the existing emails I would feel way more supported 19:24:35 well, that specific thing is not an issue if we're willing to drop the email-in-gerrit requirement 19:24:36 I feel very alone now 19:24:49 I would appreciate help way more than work on a web form 19:24:49 anteaya, my bad 19:25:02 krtaylor: not at all, you are very supportive 19:25:15 I am plagued by poor mail reader/filters 19:25:31 krtaylor: let's discuss how to fix that later? 19:26:18 the mail list would be for infra announces to all third-party service accounts only? 19:26:44 krtaylor: I think jeblair is indicating it would be used for the account requests too 19:27:16 so which way are people leaning? a) anounce list and drop the gerrit email requirement? b) drop the email requirement with no mitigating measures? c) keep the email requirement? possibly with automation to help make them more correct? 19:27:21 clarkb: i think i have 2 lists in mind now 19:27:22 so third-party-ci-announce@lists.openstack.org (or whatever) as one possible action item, maybe a different (or combined) list for related discussion and requests (can wait for that topic in the agenda)? 19:27:31 jeblair: gotcha 19:27:45 jeblair: I'd like to add before we remove anything 19:27:49 jeblair: that works for me too and means 3p operators only need to subscribe to one? 19:28:01 jeblair: to assess the effectivness of whatever we decide to add 19:28:33 I really do like the list idea 19:28:44 I'm fine trying it 19:28:47 i like the mailing list with no other contact info collection option if 1. it is well received in the weekly third-party meeting and 2. we continue to be quick with the disable-first-worry-later approach 19:29:06 fungi: i intend to do 2 regardless :) 19:29:20 yay jeblair :D 19:29:28 quick on the trigger 19:29:51 yeah. i agree that it's incumbent on the operators to subscribe to an ml and pay attention in case we let them know that whatever account was disabled why and it happens to be the one they maintain 19:30:04 it's best for everyone in the long run if people are not annoyed by 3p ci systems :) 19:30:11 very much so 19:30:11 assuming we want to do that (and give them a heads up that this is a requirement in some official documentation) 19:30:18 ++ 19:30:27 so let's segue into that for a bit 19:30:29 #topic separate mailing list for third-party ci account requests (jeblair) 19:30:33 well I'm usually annoyed so I guess that is everybody else 19:30:56 * anteaya has to stop ranting 19:30:59 so i originally proposed this because i think there are some folks on the -infra list who probably don't care about our third-party account request workflow 19:31:07 like folks from other organizations using zuul, etc 19:31:10 I'd say most 19:31:40 they are like 80% of the non-subscriber emails I let through 19:31:50 i worry that moving account requests to a separate ml, because the frequency of them has started to drown out conversation in the existing list, is indicative of other issues and we're going to see substantial scaling challenges if they continue 19:31:54 I don't mind, I can listadmin new lists too, just a thing :) 19:32:05 if they are a non-subscriber, do they get a nudge to encourage them to subscribe? 19:32:20 a nudge can be given, I don't do so right now 19:32:25 so i don't want the list to become a place where people can't actually talk about openstack infrostructure projects :) 19:32:25 fungi: I'd go with yes 19:32:36 pleia2: I'd like to request a nudge please 19:32:44 jeblair: yes, I get that 19:32:54 I'm amazed at how long some threads go on 19:32:56 anteaya: to infra ml, or to this new 3rd party one(s)? 19:33:03 pleia2: both? 19:33:08 fungi: what kind of scaling challenges? 19:33:10 wfm 19:33:14 pleia2: thanks 19:33:25 human scaling challenges, working through the incoming requests 19:33:33 thanks fungi 19:33:37 unless we make it self-service or something longer term 19:33:38 right there is quite a bit of handholding that seems to be done 19:33:43 yes 19:33:54 this group doesn't seem capable of self-serve 19:33:58 fungi: even then I am not sure that it would remove the scaling issue. It would just help with the first part of it 19:34:06 the ones that do get it are already openstack contributors 19:34:18 anteaya, that is the key 19:34:24 anyway, it's tangential to the need for it to stop impacting the usability of the existing list, so i'm in favor of the split-out. could be the same list as the third-party-ci announcements if we want 19:34:25 yup 19:34:40 doesn't matter to me either way 19:34:52 two new lists, one new list *shrug* 19:35:15 the idea for patchset for creating an account isnt a bad one, it helps fix the contributor problem 19:35:20 any change will have problems in the transition, the end goal just has to be clear for me 19:35:43 so i think the proposal is: 19:35:48 krtaylor: ah, except the panic for getting an email right becomes a panic for submitting a patch 19:36:02 they don't have to set up accounts or sign a cla to send an email 19:36:04 "steps to request a new account: #1 subscribe to the ml. #2 check these assumptions are valid (list of assumptions). #3 post a request in the following format..." 19:36:36 fungi: +1 19:36:46 a low-volume announce list that we require all third-party operators to subscribe to; only infra has unmoderated posting access. AND... 19:37:12 a third-party ci admins list where new account and account maintenance requests are sent to 19:37:15 what if (and this is just me brainstorming things) we force people to use lp/openid for these accounts 19:37:17 which list do their own outage alerts go to? 19:37:21 then the request is simply for group membership? 19:37:48 the third-party community would be welcome to participate in the second list to help new systems work through the process 19:37:55 clarkb: well, right now we don't allow web interface access for those accounts. it would be a paradigm shift 19:38:05 fungi: right, but one that would mostly allow self service 19:38:06 * anteaya notes that at krtaylor's request she is searching for a new word that means admins but isn't admins, she hasn't found one yet 19:38:15 hehheh 19:38:28 pleia2: why do they send out outage alerts? 19:38:30 i think announcements list posts should also have the reply-to set to the discussion list of we go dual-list 19:39:22 anteaya: i've called them operators. no idea if krtaylor sees a stigma with that term 19:39:33 krtaylor: ? 19:39:35 jeblair: some send them to -dev and get in trouble 19:39:37 fungi: i think infra is the discussion list 19:39:41 i also call myself a systems administrator, so i'm not entirely sure i understand teh concern 19:39:50 not a big deal really 19:39:56 so it seems some do want to announce outage alerts, but maybe they shouldn't? 19:39:57 jeblair: fair enough. we could set follow up to -infra in the headers then 19:39:59 I'm fine with operators 19:40:32 pleia2: if dev doesn't want announcements of third-party ci sytem outages, then perhaps dev doesn't want their third-party ci system at all and they can just close up shop and save everyone some work. :) 19:40:42 fair enough 19:40:45 pleia2: we addressed the need to announce outage alerts with the wikipage 19:41:07 but i _definitely_ don't want to see them; i think the only potential audience is in -dev. 19:41:26 (i only care about systems that are posting, not systems that aren't) 19:41:38 i guess it's reasonable for the third-party operators to update the wiki systems list with status information when they have/resolve an outage 19:41:47 anteaya: ok, guess I missed that, sorry 19:42:00 as long as all the projects relying on input from these know where to look when they notice the absence of an expected vote on a change 19:42:03 pleia2: np 19:42:07 #link https://wiki.openstack.org/wiki/ThirdPartySystems 19:42:18 so let me draft some 'agreed' statements and you can tell me if we're really agreed 19:42:19 we having pointed to it yet on the ml 19:42:34 fungi: yes 19:42:41 anteaya: thanks for the link 19:42:57 also they need to announce status so their overall status in the project is uptodate 19:43:03 as in they are communicating 19:43:15 so they won't have their driver pulled from master 19:43:43 so I get the need, we just need an agreed upon, used, non-spammy way to do it 19:43:56 grantbow: welcome 19:44:00 anteaya, we should put status on the individual template too 19:44:20 krtaylor: I leave that magic to you, I am not opposed 19:44:34 agreed create third-party announce ml which is low-volume, infra -> third-party broadcast only, expect all third-party admins to subscribe 19:44:34 agreed create third-party request ml which is open subscription where third-party systems sent account requests 19:44:34 agreed third-party accounts no longer need to provide gerrit email addresses 19:44:34 agreed third-party system status goes in wiki page 19:44:38 agreed subscription to third party announcements list required of all operators, agreed separate third party account request mailing list where other operators are encouraged to help newcomers through the process 19:44:42 do those all look right? ^ 19:44:46 * krtaylor wishes he was a better magician 19:44:47 yes 19:44:58 jeblair: yup 19:45:07 jeblair: yes 19:45:13 jeblair: in favor, aye to all four 19:45:19 what does open subscription mean? 19:45:29 anteaya: it means anyone can join. like the -dev list 19:45:36 clarkb: k, thanks 19:45:39 #agreed create third-party announce ml which is low-volume, infra -> third-party broadcast only, expect all third-party admins to subscribe 19:45:40 #agreed create third-party request ml which is open subscription where third-party systems sent account requests 19:45:40 #agreed third-party accounts no longer need to provide gerrit email addresses 19:45:40 #agreed third-party system status goes in wiki page 19:45:41 anteaya: anyone who joins can post to the list 19:45:53 fungi: thanks 19:46:05 clarkb: to your point about lp accounts and group membership. it's tempting, but i'm worried that they will be used the wrong way if they can be... but i think it merits further thought. 19:46:07 who is the ml creator? 19:46:12 pleia2: is that you? 19:46:22 jeblair: ya I think that is the biggest concern. people may use them to push code and other things 19:46:34 jeblair: so we may have to figure out gerrit side acls that make thigns safish 19:46:34 anteaya: there is a file in config you update 19:46:39 if there is an unimaginable wrong way to do something, this group will find it 19:46:43 clarkb: maybe... maybe with sufficient acls we could get that to work. 19:46:47 they should be quality control 19:46:49 jeblair: clarkb: worth more thought. maybe we can restrict the access currently granted to normal users if they're in the systems group or whatever 19:46:54 er, that 19:47:05 who wants to create the patch? 19:47:21 I'm still conferencing so I am a bad choice 19:47:26 I would otherwise 19:47:28 :( 19:47:34 it's an easy enough patch, I can do it 19:47:36 i am happy to submit the change to create the mailing lists 19:47:41 or pleia2 can to it! 19:47:50 * fungi quickly backs away from the keyboard 19:47:51 fungi, clarkb: i think we should proceed with what we've got (the only thing that may change is we may drop the request list), and plan out the other idea further 19:47:55 lol 19:48:03 #action pleia2 create new mailing lists 19:48:06 pleia2: thanks, link me for the review 19:48:06 jeblair: sounds good 19:48:16 jeblair: ya I think my brainstorming alternative will need more time and thought 19:48:24 whereas the list stuff is cheap and quick 19:48:26 good for now 19:48:32 oh my, this meeting is almost all third-party this week 19:48:38 #topic comment syntax for third-party CI recheck (dougwig, from third-party CI meeting) 19:48:47 we are a rowdy bunch 19:48:56 do dougwig had to jet at half past 19:49:06 it's almost like the third-party operators need their own weekly meeting. oh, wait, they have one! 19:49:12 whoopsie; if people mention that in the agenda, i can accomodate 19:49:17 the upshot is that third party doesn't want to break things like vmware did last week 19:49:37 so how should we recheck for now, until we can agree to how we should recheck long term? 19:49:38 this rolls into the next topic, so maybe we just cover both as one discussion 19:49:51 I have told them manual recheck is acceptable, not generated scripts 19:50:07 pleia2, can you tag the topic of the maillist patch third-party? 19:50:10 what else should they know to safely recheck? 19:50:17 oh yeah, it's never okay to mass-recheck by leaving comments 19:50:24 krtaylor: sure 19:50:24 oh, how should they do mass rechecks? they should trigger them in whatever way their systems allow without leaving comments in gerrit to do so 19:50:25 neither jenkins nor zuul requires that 19:50:50 jeblair: yes, we covered not mass-rechecking in yesterday's meeting 19:50:55 here's my topic intro: "hi there. A topic came up in the third-party CI meeting, which was to refrain from using recheck.* as a prefix for triggering re-checks in 3rd party CI's, as it causes standard jenkins to also re-run. What syntax/prefix should we use/standardize for retriggering a single third-party CI?" 19:50:59 (i'm not really here) 19:51:00 which motivated the current agenda item 19:51:05 dougwig: yay 19:51:12 #link https://review.openstack.org/#/c/109565/ 19:51:21 so there's a change that proposes a syntax. 19:51:26 it has nothing but red votes 19:51:30 yes 19:51:36 so there is a conversation 19:51:48 they just want to know what is safe which the conversation takes place 19:52:02 so they aren't blocked until resolution of the conversation 19:52:07 i think some people can't agree on the syntax, and i think some people (myself and fungi included) don't agree that third-party ci specific recheck comments should be used at all 19:52:12 or is there a safe way 19:52:23 there are also a bug and an infra ml thread on this topic 19:52:27 anteaya: what is the safe way to do a third-party specific recheck comment? 19:52:39 yes, that is the question 19:52:43 I do believe 19:52:49 #link https://launchpad.net/bugs/1355480 19:52:50 Launchpad bug 1355480 in openstack-ci "recheck/reverify comment_filter is too loose" [Undecided,Opinion] 19:52:54 anteaya: there is no safe way, it's not supported or recommended 19:53:00 hmmmm 19:53:00 I agree with jeblair and fungi 19:53:04 its the wild west we don't enforce it 19:53:05 #link http://lists.openstack.org/pipermail/openstack-infra/2014-August/001681.html 19:53:07 there is no "safe" 19:53:25 okay well this places those operators wanting to play by the rules in a difficult spot 19:53:34 I don't know what to take back to them 19:53:51 I've worked so hard to get them to ask 19:54:07 I would be really disapointed if I went back with "do whatever you want" 19:54:14 the rules say they should rerun their checks when someone leave a "recheck bug [0-9]+" or "recheck no bug" comment 19:54:25 anteaya: i don't think i'd say that. i think i'd say what fungi said. 19:54:26 at least in present documentation 19:54:45 i mean, something like "thirdparty-recheck-a10", or anything that will never match your jenkins, is all we want. 19:55:04 dougwig: i'm unconvinced there's value in rerunning only one ci system 19:55:04 i believe we attempted to have a stronger indication that nothing else should be supported, but that did not gain unanimous approval. thus the 3p ci operates in an undefined area if they do anything more. 19:55:06 we can make it up; wasn't sure if there should be a standard. 19:55:14 is dougwig's suggestion safe? 19:55:19 fungi: retrying false negatives. we are not all as perfect as infra. :) 19:55:24 it's not like we allow developers to only rerun the jobs which fail and leave the passing results for other jobs. it should eb all-or-nothing 19:55:32 yeah, everyone wants to make some super complicated language for controlling ci systems in comments 19:55:50 that's an INSANE idea, and the only reason we do it at all is because our tooling is not good enough to support something else 19:55:59 i mean, it's a horrible user interface for developers 19:56:00 we ask people to start commenting before they vote, to shake out bugs. not every failure is a fault in the submitted code (many are not for 3p) 19:56:04 and we should minimize it's use totally 19:56:13 I think they are just trying their best to not step on infra's toes and allow functionality they percieve as necessary 19:56:37 i don't think we'd be upset if someone says "recheck". i mean right now we re-run jobs all the time for no particular reason :) 19:56:53 the issue with recheck bug # is that all ci systems will start over again. As there are more and more, the probability of all of them passing gets smaller, especially when there are intermittent bugs. 19:57:05 we just don't want to create a scenario like vmware did that brought down zuul last week 19:57:16 anteaya: these are two separate issues 19:57:21 jeblair: yes 19:57:22 anteaya: a different syntax doesn't solve that problem 19:57:27 clarkb: oh 19:57:43 we are almost at time and I feel we are at a stalemate for now 19:57:45 anteaya: at least as long as clean check si a thing any comment can trigger CI 19:57:53 anteaya: the main problem i saw is that a bot went and left hundreds of useless comments on changes 19:57:57 anteaya: we will disable any account for spamming regardless of what syntax they use 19:58:00 so no bots 19:58:09 jeblair: true 19:58:22 not no bots. just bots should only leave comments which contain useful information for reviewers 19:58:23 what i'm hearing is that you think the mechanism is a bad idea in general. i think that's overly optimistic in terms of the quality of all of these disparate CI systems. 19:58:25 I think we covered not bots for comments, but I can cover that again 19:58:38 fungi: okay 19:58:49 in an ideal CI world, it would not be needed. the world is not currently ideal. or even close. 19:58:53 (useful and nonredundant) 19:59:12 fungi: k 19:59:24 dougwig: there's an opportunity in https://review.openstack.org/#/c/109565/ 19:59:38 i'm also worried that we risk sending a signal that it's okay for things to work poorly, and we should give up bothering to improve that 19:59:47 dougwig: right now, no one likes that change at all. perhaps if even a handful of people could agree on what would be a good idea, it will go somewhere. 19:59:56 I'm all for improving our signalling 20:00:18 and we have no more time 20:00:24 or maybe someone should add authentication to zuul's webui so recheck requests don't have to go in comments :) 20:00:31 that would be a far better use of all of our time, i think. 20:00:34 thanks everyone! 20:00:35 not specifying a syntax will result in every 3p system making up its own recheck trigger. i think the idealist case won't fly in reality. 20:00:37 #endmeeting