18:02:34 #startmeeting trove 18:02:34 go go go 18:02:34 Meeting started Wed Apr 30 18:02:34 2014 UTC and is due to finish in 60 minutes. The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:38 The meeting name has been set to 'trove' 18:02:42 o/ 18:02:46 ok we need to beat 16 minutes 18:02:46 o/ 18:02:46 o/ 18:02:48 o/ 18:02:49 o/ 18:02:52 woot woot 18:02:52 o/ 18:02:53 o/ 18:02:54 Agenda: 18:02:55 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:03:00 o/ 18:03:01 o/ 18:03:05 o/ 18:03:07 o/ 18:03:12 |o| 18:03:15 Hello everyone. 18:03:15 \o 18:03:16 o/ 18:03:19 gooooool 18:03:26 |-o-| 18:03:28 good day all, im here and happy to be here 18:03:36 cp16net: lol 18:03:37 i refuse to make ascii art of myself 18:03:38 cp16net: wheres the a? 18:03:44 but i am, in fact, a part of this meeting 18:03:59 0/ 18:04:02 you can tell by the text im submitting to this channel 18:04:03 Alright, let's get started. 18:04:05 #topic Establish policy for disk image builder elements for datastores 18:04:09 o/ 18:04:15 My colleages have submitted a couple of Gerrit changes (https://review.openstack.org/77461 and https://review.openstack.org/79413) that have been -1ed because they lack Fedora diskimage-builder (DIB) elements. 18:04:16 o/ 18:04:21 Goal: Establish a policy regarding Gerrit changes that add a DIB element. 18:04:22 has anyone seen hub_cap? Is he here? :-) 18:04:27 ;) 18:05:01 o/ 18:05:15 Other items to consider are here: https://wiki.openstack.org/wiki/Meetings/TroveMeeting#Agenda_for_Apr._30 18:05:30 \o 18:05:54 I'm all for Fedora and Ubuntu parity. But parity can come piecemeal (as it does for the datastore managers). 18:06:00 The dangers in requiring parity up-front include: higher potential of Abandonment, potential reduced quality of the "other" DIB element, lack of testing on Fedora at all... 18:06:26 Obviously I'm biased but the point is to just establish a policy whatever that may be. 18:06:33 I think I started the fedora issues. I think testing fedora might be onerous, but I think that fedora elements should always be added, and if they're not tested should just throw an error. 18:06:39 given that we don’t enforce supporting a new feature across all datastores at once, it makes sense that we don’t enforce support of a datastore across all distros at first-go. 18:06:57 amcrn: +1 18:07:03 (with a suitable message) 18:07:28 amcrn: +1 18:07:29 is the conversation about supporting datastores on multiple distros or simply being able to kick-start them in a test/development environment 18:07:38 kevinconway: former 18:07:55 plus if they are not available or don't work wouldn't you use the distro that did? 18:08:00 So, as a user here, in that case how do I know what's the state of support for a particular datastore for a particular distro? 18:08:22 at the risk of dragging up the "support matrix", does it now mean that we need to make one that includes both datastore and guest OS? 18:08:24 SlickNik: as the datastore-version story matures, the feature matrix can indicate such things 18:08:29 SlickNik: does trove have official support for all or any distros other than ubuntu 12? 18:08:29 For me, the issue is that when someone goes to test something on fedora, the state should be obvious. They shouldn't have to go tracking down why something that works on ubuntu doesn't work on fedora. 18:09:35 I haven't used Fedora but can someone give me an example of something that works on ubuntu but not fedora 18:09:40 but isn't this just for the DIB? 18:09:56 if you want to deploy you should build your own images 18:09:58 kevinconway: I think as an OpenStack project we need to support both Fedora as well as Ubuntu. 18:10:03 Right now, I don't know if anything works on fedora, at least not F20. 18:10:13 In case you didn't check out the meeting agenda: Cassandra and Couchbase are merged and do not have Fedora DIB elements. 18:10:17 It never gets testes AFAIK. 18:10:25 what does this mean when it comes to gating? will we run the tests on both distro? 18:10:48 So let's constrain the scope of this discussion to just the DiB elements for now. 18:11:14 maybe we can address each step of the process separately to keep this from turning into a tornado 18:11:23 so the only difference between the DIB for ubuntu and fedora is apt vs yum right? is there more to this? 18:11:35 I'm going to take an action item upon myself to check what other OpenStack projects do when it comes to testing on multiple distros (ubuntu / fedora in particular) 18:11:41 Yes, there are some small system differences. 18:12:02 kevinconway: also upstart vs systemd, there might be more... 18:12:09 so what is the success critteria of building a disk image? 18:12:19 +1 juice and SlickNik. the very targeted question at the moment is: right *now*, does the introduction of a new datastore-version (and/or datastore) require adding dib-elements for both ubuntu and fedora in one-shot 18:12:54 amcrn: I would say adding a new datastore only requires it to work with ubuntu 18:13:04 or ubuntu only 18:13:11 Then why have fedora at all? 18:13:13 i think it makes sense to piecemeal the dibs but make sure it works for ubuntu 18:13:20 amcrn: :-) that depends on the datastore's binary packages and its distro-support 18:13:30 because ubuntu is the test bed 18:13:42 vgnbkr: I would see fedora as "optional" at this point 18:13:59 then why don't we just take fedora support out until we're ready to deal with it properly? 18:14:24 vgnbkr: because we may have support for SOME data stores on fedora 18:14:26 juice : optional means .. not officially supported indirectly ? 18:14:33 so the matrix is datastore/distro 18:14:50 vgnbkr: that's akin to saying: let's take out backups because they're not supported for all datastores. it's up to the stakeholders that care about a particular feature and/or distro to further their own interests. 18:14:57 every datastore should have a check in the ubunto distro column 18:15:23 we keep saying support fedora vs support ubuntu. isn't this only about kick-starting in a dev environment? 18:15:28 kevinconway: no 18:15:35 i think this is an openstack policy question, and maybe should be discussed at project meeting 18:15:37 this isn't to say that missing DIBs from trove-integration prevent a deploy of a datastore 18:15:43 amcrn: that's different - it is expected that the stake holder will fix it. In this case, who is the stakeholder for fedora? 18:15:43 I think we should at least be consistent across datastores: if datastore_a/v1 supports both then datastore_a/v2 should too 18:16:08 kevinconway: the problem right now is we're getting reviews -1'd because dibs don't exist for fedora, and are only being introduced for ubuntu 18:16:24 amcrn: that is a problem 18:16:28 vgnbkr: whoever wants to deploy on fedora 18:16:32 amcrn: right, but that's not supporting a distro. that's setting up a dev environment 18:16:33 amcrn: Yeah- we need to stop that 18:17:07 kevinconway: is your question, what does "support" mean...officially? 18:17:08 we have quorum then, yes? no -1'ing a ubuntu-only dib-element introduction. 18:17:25 what guarantees do we offer on this software? it passed the gate? 18:17:36 amcrn: we can vote on that 18:17:49 Okay, let me propose a plan of action. 18:17:54 amcrn: So all I'm suggesting is that when a change is made to ubuntu, if the corresponding fedora elements aren't updated/created, there be a placeholder to indicate that that element is not supported. 18:18:01 i think we should consult the mordred 's of the world too 18:18:15 im not sure what our "requirements" here are 18:18:19 I'll check with the other OpenStack folks about this. 18:18:39 SlickNik: Is the plan to test / gate all datastore managers and versions against both Ubuntu and Fedora? 18:18:49 I'm not 100% sure what the official openstack position is regarding asymmetric support across distros. 18:19:08 I can't see a surefire way we can know if the corresponding fedora elements are updated or created if we don't 18:19:10 SlickNik: you are now responsible for all decisions made in openstack up to the point you became PTL 18:19:30 kevinconway: That's so comforting to know. :) 18:19:31 SlickNik: i'm not sure why the answer to that question should prohibit inflight reviews, considering if the answer is "it should be asymmetric" we're already wayyyyyy out of compliance 18:19:52 amcrn: Agreed. 18:20:30 amcrn: Because it dictates whether our priority should be to drag us back into compliance vs. to add more datastores getting us further away. 18:21:30 Trove already is going to have a ton of datastores, which means a ton of testing. Regardless of OpenStack's take, my guess is we will not be able to gate on testing for every single datastore and version for every distro. 18:22:31 grapex: the number of permutations would be quite high at this point 18:22:32 maybe we should get datastores to work in general 18:22:39 robermyers: +1 18:22:48 grapex: testing till today is for trove functionality .. not for distro support ... and you are right that way 18:22:53 cause it sucks trying to use more than one 18:22:59 Stupid question: This code runs on the guest...one level up from OpenStack "proper" which is what keeps getting referenced as the standard for being symmetric. Is it a fair comparison? 18:23:06 grapex: We should have the stakeholders who are interested in adding the datastores to Trove, also do the testing using some sort of 3rd party infra. 18:23:30 time-check 18:23:54 SlickNik grapex: the problem is, if it's made this difficult to support other versions, the amount of inflow of public code will dry up. 18:23:59 mat-lowery: Good point 18:24:05 maybe just test the guest on those distros 18:24:29 hub_cap: what did I do? 18:24:39 what didnt u do :) 18:24:48 * mordred throws wet cat at hub_Cap 18:25:10 mordred: we install datastores, do we have to, by default, make sure that we support fedora and ubuntu for all datastores? 18:25:14 amcrn: Right- which is why I don't think we should gate on all the permeatations introduced by testing Fedora on every single datastore 18:25:19 ^ ^ we an talk after w/ SlickNik, mordred 18:25:29 and mordred, i do wash my cat, ask imsplitbit 18:25:29 grapex: means there will be multiple test runs .. following instance create .. for each distro ? 18:25:39 mordred: Support for a few new datastores are being added to Trove, and we're discussing whether there is a cross OpenStack requirement to support a Fedora guest as well as an ubuntu guest. 18:25:52 grapex: agreed. 18:26:25 hub_cap: not really 18:26:38 ^ ^ decree 18:26:56 hub_cap: right now the policy is "dev targets latest ubuntu/fedora but may not do anything that prevents running on latest LTS or RHEL" 18:27:23 we don't gate on fedora anywhere in the system at the moment, because fedora and ubuntu have the same python 18:27:25 NOW 18:27:26 ok but if we are all runnin ubuntu, we wait for someone to care about fedora? 18:27:31 yup 18:27:34 if you guys do a C-based agent 18:27:37 mordred: I like it 18:27:42 LOL 18:27:45 mordred: This sounds theoretical.... 18:27:47 we probably want to escalate making sure it works on fedora 18:27:49 just saying 18:27:49 lol 18:28:00 mordred: But C is hard 18:28:17 Also not enterprise webscale. 18:28:18 IIRC you have to do bit twiddling extensively just to print a hello world. 18:28:38 grapex: python3? 18:28:55 Okay, time check. 18:28:59 looks like i am going to start doing more testing against ubuntu for my stuff :) 18:29:18 heh atomic77 :P 18:29:21 robertmyers: Good point- we at some point may want to test in Python 3 if the guest will be running on it and some canonical capacity 18:29:32 can we move on to the sub-item of discussing the use of PPAs? 18:29:47 Sure 18:29:50 I'm not sure where we landed here. 18:30:06 #startvote What should we do to ubuntu-only dib element patchsets. +1, -1, figure_out_requirements 18:30:07 Unable to parse vote topic and options. 18:30:11 lol 18:30:16 Let's table this for now. 18:30:28 mat-lowery: Let's move on to the next sub-item 18:30:54 ok. This is SlickNik's silent scope creep on my agenda item. :) 18:31:05 Do we have a policy on how the bits are laid down? 18:31:18 Package Install vs. Tarball Install vs. Source Install 18:31:35 I think it would be what is avail for the datastore? 18:31:38 mat-lowery: is this for trove packages only? 18:31:47 or for dependencies as well 18:31:52 juice: This is for the datastore. 18:32:07 trove-guest only then.. 18:32:43 cweid: wait- hang on. I want to go back to "c is not webscale" 18:32:57 enterprise webscale. 18:32:58 ...as part of the reference guest install process 18:33:08 juice: As it was conceived, just the datastore. mysql-server deb 18:33:28 I think at some point we decided that we would use official distro packages. 18:33:33 mordred: dont feed the trolls :) 18:33:47 SlickNik: we did? ;) 18:33:48 But the issue is that for some of these new datastores, no official distro packages exist. 18:33:51 i beleive we've stuck to package install with official supported versions from vendors 18:34:12 That's not true 18:34:23 i dont think redis is a pkg 18:34:25 is it? 18:34:25 There is currently a PPA-based, merged DIB: Redis on Ubuntu. 18:34:26 I use some random PPA to install redis 18:34:27 amcrn: I'm using "decided" loosely here. There was no official decision. 18:34:39 so to sound like a broken record 18:34:41 fwiw - OpenStack has no official policy on this - other than that _We_ do not make packages 18:34:45 this is development, not production :) 18:34:52 hub_cap: +1 18:34:54 ymmv for installing production 18:35:04 as an extension of earlier conversatiion, wouldn't the answer be that the one(s) concerned about that datastore will pick the packages that must be installed? 18:35:05 we should find _a way_ to run the version we advert we run 18:35:55 but again, if you are running some ppa in production, thats on you, if, say, it goes down or something else happens 18:36:11 hub_cap: the problem lies in what is actually *supported* via the managers 18:36:22 god knows if that random ppa diverges from the official package, etc. 18:36:26 our goal should be that installers can use upstream DIBs to do a produciton install.. 18:36:27 for more "experimental" data stores (cough) obviously we would not a policy that states that packages must come from the official repos 18:36:31 sure amcrn and i think we need to find _a way_ to install our version we support 18:36:52 if we need to do something special for development.. fine.. but make that param driven in the DIB 18:36:53 atomic77: yea i dont think we _have_ to come from the official repos 18:37:13 amcrn: i think we should do our best to pick a ppa that doesnt rewrite a datastore functionality 18:37:28 how is it possible to even certify that scientifically? 18:37:34 other than "looks like it" 18:37:40 but maybe it makes sense to simply warn when a data store is not using official packages 18:37:50 amcrn: well, our other option is to build everything from source :) 18:37:51 and the user ideally knows what they are doing 18:37:58 i'm 100% against a ppa-based install unless the author of the ppa is the actual maintainer of the project 18:38:05 Okay. I think the general consensus that that it's okay for our dib _dev_ elements to pick up a PPA, but we need to make it aptly clear what PPA's packages our manages are _actually_ tested against. 18:38:22 +1 amcrn that makes sense 18:38:31 other options are that we (amcrn) creates a ppa for all pkgs 18:38:39 or we just build from scratch in the dib element ;) 18:38:55 Boy do I love those options. :) 18:39:20 and we're no closer to figuring out what is mergeable 18:39:40 fwiw, i totally think a ppa is fine, and if we find a ppa that does what amcrn is thinking, im sure itll become a bug in our system 18:39:47 and we can fix it _when_ it happens 18:39:59 ;) 18:40:06 https://launchpad.net/~ondrej/+archive/mysql-5.6 18:40:10 I mean we can't just maintain packages for N number od databases 18:40:11 https://launchpad.net/~rwky/+archive/redis 18:40:13 Or have datastore versions be tied to package source, i.e., mysql-5.5-cononical 18:40:14 we could use that tomorrow heh 18:40:28 Okay, time-check. 18:40:30 vgnbkr: but then we have to build that, right? 18:40:51 yea this sounds like a good bargument at openstack summit 18:41:05 hub_cap: no, I'm saying it's a defined source for that datastore version, so it's OK to get it from the defined source. 18:41:34 ugh maybe we should do this 18:41:58 1) stop installs, and force upgrades to be a "deploy to new image" 18:42:03 So we would have mysql-5.5-canonical, mysql-5.5-oracle, mysql-5.5-percona, etc. 18:42:03 sorry taht was #2 18:42:25 if we say "you must provide your version in the image" then we dont have the issue of using apt/blah/blah at _all_ 18:42:34 and for development we can do whatevs 18:42:45 but we can remove all of the install logic / apt/rpm logic from the code 18:42:53 hub_cap: +1 18:43:00 and migrations / upgrades are new instances / migrations 18:43:08 err upgrades are new instances/migrations 18:43:26 Okay, trying to reign this one in. 18:43:29 * hub_cap puts down his wrench 18:43:38 How does that solve the problem of knowing which versions of DB x work with the guestagent code? 18:43:41 hub_cap: i agree with you, that still doesn't answer the question of: what is merge'able as a dib-element. can it be a ppa? can it be a long-winded 500 line shell script? 18:44:12 amcrn: build from source ;) 18:44:23 then it wont matter tho honestly 18:44:35 a ppa would be fine, and if it diverges, we will find out when we get a bug listing 18:44:43 honeslty even w/o my wrench that would work 18:44:50 amcrn: I don't understand the issue - as long as it is consistently retrievable and something we have tested against why does it matter 18:45:02 juice: +100 18:45:11 Also 18:45:13 juice: +1 18:45:19 I guess it would have to be universally retrievable - i.e. on the internet 18:45:19 we might want to just treat this on a case by case basis 18:45:38 otherwise we can build em ourselves 18:45:46 hub_cap: -100 18:45:47 and stick em up in lp 18:45:59 juice: The manager is tied to the bits on disk. There has to be some somewhat standard place to look for the binaries, etc. 18:46:01 juice: just got a phone call, sory 18:46:48 Okay for mergeability: 18:46:49 #startvote Allow PPAs in DIB elements? yes, yes_but_only_if_project_official, no 18:46:50 Begin voting on: Allow PPAs in DIB elements? Valid vote options are yes, yes_but_only_if_project_official, no. 18:46:51 Vote using '#vote OPTION'. Only your last vote counts. 18:47:09 #vote no 18:47:14 #vote yes 18:47:17 #vote yes 18:47:23 #vote yes 18:47:24 #vote yes 18:47:27 #vote yes 18:47:28 #vote yes 18:47:29 #vote yes 18:47:33 #vote yes_but_only_if_project_official 18:47:45 #yes_but_only_if_project_official 18:47:46 #vote yes_but_only_if_project_official 18:47:46 I don't get that? 18:47:49 shoot 18:47:51 What makes it official? 18:47:52 #vote yes_but_only_if_project_official 18:48:04 who makes it official? 18:48:12 cweid: the PPA is by a project maintainer 18:48:17 What is there is not one? 18:48:20 cweid: I would say that we have gate test around it but that is seriously limited 18:48:21 and no debs 18:48:27 #vote no 18:48:28 SlickNik: A maintainer of the datastore? 18:48:40 grapex: yes 18:48:48 #showvote 18:48:49 yes (7): robertmyers, konetzed, grapex, imsplitbit, cweid, rueb7363, atomic77 18:48:50 yes_but_only_if_project_official (3): mat-lowery, SlickNik, juice 18:48:51 no (1): amrith 18:49:14 looks like yes_but_only_if_project_official won ;) 18:49:17 #endvote 18:49:17 Voted on "Allow PPAs in DIB elements?" Results are 18:49:18 yes (7): robertmyers, konetzed, grapex, imsplitbit, cweid, rueb7363, atomic77 18:49:19 yes_but_only_if_project_official (3): mat-lowery, SlickNik, juice 18:49:20 no (1): amrith 18:49:25 Given this vote, can we at least state that PPAs should not be the first choice? 18:49:27 oops i missed the vote 18:49:38 that was weird 18:49:41 official repos sohuld always be first 18:49:45 * amrith different 18:49:46 totally 18:49:49 then rando dude ppa 18:49:52 then build from scratch 18:49:54 what's your vote hub_cap? 18:50:03 my vote is to vote against juice 18:50:07 Too late he missed the vote. 18:50:07 in general, in life 18:50:13 that leave you two options 18:50:15 yes or no 18:50:32 So allow it. But let's make a best effort to follow this order: distro package, project maintainer PPA, some random PPA. 18:50:35 We have like 50 million options 18:50:44 If there is a package in the distro use it 18:50:50 if not 18:50:56 find some other place to get it? 18:51:02 Why would someone add a PPA if an official option existed? 18:51:03 I don't see how this is really an issue? 18:51:09 so is there such a thing as "project maintainer ppa" 18:51:10 Seems mean. :/ 18:51:16 Can we just have an order of operations? 18:51:17 Case by case basis of course but Redis PPA was chosen because it was a newer version. 18:51:25 grapex: modified slightly for perf / whatever. 18:51:37 mat-lowery: and im sure the same would be said wrt my5.6 18:52:10 Okay, I think we've beaten this to death. 18:52:14 LEt's move on. 18:52:23 #topic Open Items 18:52:38 SlickNik: didn't you have a topic about commit messages? 18:52:42 Was the -1 for comments issue covered? 18:52:49 i have soemthing i wanted to mention as well 18:53:01 Yes, I did. 18:53:05 It's short. 18:53:11 iccha: you can go first. 18:53:33 neha wanted us to look at https://wiki.openstack.org/w/index.php?title=Trove/list-datastore-type-and-versions 18:53:42 she made changes after bp was approved 18:53:47 to the api response 18:54:35 iccha: that looks good 18:54:45 thanks iccha. 18:55:00 nice and backward compatible 18:55:00 yeah it was additive of the versions 18:55:13 ya basically i made the change for augmenting the existing call and changed the format of the response 18:55:34 now versions are nested within each db type 18:55:48 iccha / NehaV: Looks good to me at a quick glance. 18:55:58 thanks for taking a look ! 18:56:17 SlickNik: So about that -1 comment thing 18:56:33 Okay, so I just wanted to chat a bit about the −1 on Commit messages. 18:56:35 What's a good idea of the kind of commit message styles that are getting -1'd which you think shouldn't be? 18:56:55 I've seen a bunch of them that say "Please provide Reasons / Changes" 18:58:00 I'm not sure how the "Reasons / Changes" requirement came about, but I don't think we should mandate it. esp for a 1-2 line change. 18:58:26 SlickNik: oh mean in the commit message 18:58:30 #link https://wiki.openstack.org/wiki/GitCommitMessages 18:58:39 no reason / change 18:58:42 yeah i dont think that its a big deal 18:58:54 I don't like seeing that either 18:59:01 I think it's fair that reasons/changes should be apparent to the reviewer, but it shouldn't be necessary to have explicit sections. The reviewer should use their judgement. 18:59:05 Thanks robertmyers, I was looking for that. 18:59:06 I actually think it's a huge waste of text to have to write the Changes especially 18:59:12 -1 reasons/changes 18:59:15 gotta run out a little early see you guys next week. Have a good week! 18:59:15 just put a paragraph 18:59:17 the "Changes" are already in the git difference which itself is the commit 18:59:31 and the "reason" should be in the commit msg anyway- there's no need to title it as such 18:59:38 see you cweid 18:59:38 are there any rules against lorem ipsum commit messages? 19:00:05 hehe : i got a -1 for putting reasons/changes :D 19:00:21 thanks hub_cap <3 19:00:42 kevinconway: I think that's pretty much what the "Reason / Changes" format is 19:00:50 SlickNik: Can we vote? 19:01:38 https://review.openstack.org/#/c/86808/ 19:01:38 plz view that commit msg 19:01:38 and yes juice has noted i misssepellld separation 19:01:38 grapex: +1 19:01:38 Another thing I want to get a quick opinion on. 19:01:38 Do we require a bug for all changes? 19:01:38 we used to say yes 19:01:38 yes 19:01:38 but im tihnking no, if its a spelling change 19:01:38 what abt stuff like spelling mistakes? 19:01:38 if its small i dont think so 19:01:38 or a trnsifex 19:01:39 I have had folks ask for more descriptive messages tho 19:01:39 or something mordred does on tox 19:01:39 but if its bigger than a line or 2 i think we should 19:01:39 no spelling change commits 19:01:39 lol robertmyers 19:01:39 SlickNik, I thought it was BP or BUG 19:01:41 I think I agree with the general sentiment. 19:01:42 robertmyers: +1 19:01:47 SnowDust: ;) 19:02:02 whats the settlement SlickNik ? 19:02:12 #startvote Require bug, or bp? yes, no 19:02:12 the meeting is over. 19:02:13 Begin voting on: Require bug, or bp? Valid vote options are yes, no. 19:02:15 Vote using '#vote OPTION'. Only your last vote counts. 19:02:22 iccha: i don't discuss settlements without my lawyer present 19:02:26 #vote no 19:02:30 #vote yes 19:02:30 hurry!!!!! 19:02:33 we are over 19:02:34 I think the idea is that we don't need it for small changes. 19:02:35 #vote no 19:02:35 #vote no 19:02:38 #vote not always 19:02:39 #vote no 19:02:40 cp16net: not always is not a valid option. Valid options are yes, no. 19:02:45 way to go cp16net 19:02:46 #vote no 19:02:47 #vote no 19:02:49 man cp16net! 19:02:52 #vote yes 19:02:53 :-/ 19:02:58 #vote no , not always :) 19:02:59 hub_cap: no , not always :) is not a valid option. Valid options are yes, no. 19:03:15 any more takers? 19:03:18 #vote yes 19:03:25 vote-bot don't take no 'ish 19:03:31 juice: lol! 19:03:34 lol 19:03:40 we should make it explicit under what conditions it is ok not to have a bug or bp 19:03:48 #vote falsey 19:03:48 robertmyers: falsey is not a valid option. Valid options are yes, no. 19:03:52 #endvote 19:03:52 iccha: +1` 19:03:53 Voted on "Require bug, or bp?" Results are 19:03:55 yes (3): robertmyers, amrith, vgnbkr 19:03:57 no (6): SlickNik, SnowDust, juice, cp16net, grapex, hub_cap 19:04:04 #vote no 19:04:04 the yea's have it 19:04:14 * amrith rejoices 19:04:18 lol 19:04:27 #endmeeting