19:02:38 <jeblair> #startmeeting infra
19:02:38 <pleia2> o/
19:02:39 <SergeyLukjanov> o/
19:02:40 <openstack> Meeting started Tue Jun  3 19:02:38 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:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:44 <openstack> The meeting name has been set to 'infra'
19:02:52 <jeblair> #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting
19:02:54 <jeblair> agenda ^
19:03:01 <jeblair> #link http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-05-27-19.00.html
19:03:04 <jeblair> last meeting ^
19:03:17 <jeblair> nothing from last meeting so
19:03:23 <jeblair> #topic  manage-projects status (fungi)
19:03:53 <fungi> howdy
19:04:11 <jeblair> fungi: are there any errors we should be looking out for still?
19:04:19 <jeblair> i noticed we created a couple more projects recently
19:04:48 <fungi> looks like the fix which i had proposed is no longer waiting on https://review.openstack.org/94196
19:05:00 <fungi> so just needs reviewing/approving
19:05:11 <fungi> #link https://review.openstack.org/94684
19:05:20 <fungi> i haven't spotted any new failures though
19:05:34 <clarkb> there was the github failure to set account rights
19:05:42 <clarkb> but other than that I haven't seen anything
19:05:45 <fungi> clarkb: oh, right. there was
19:06:03 <krotscheck> o/
19:06:12 <bcrochet> o/
19:06:12 <fungi> that we've so far attributed to github api call failures or throttling, but i don't know if anyone has gone digging in the puppet logs yet
19:06:37 <jeblair> we might see it if we approve all those xstatic changes
19:06:41 <fungi> it's happened a couple times in the same pattern though, in as many months
19:06:51 <fungi> quite possibly
19:07:10 <anteaya> 16 repos in that xstatic patch
19:08:08 <SergeyLukjanov> yeah, it'll a good test for manage-projects
19:08:17 <jeblair> okay, so next time we see the github thing, we should probably start digging into the logs
19:08:24 <mordred_phone> ++
19:08:32 <fungi> yes
19:08:33 <jeblair> #topic  Review Third Party wiki templates (anteaya)
19:08:46 <anteaya> #link https://wiki.openstack.org/wiki/Template:ThirdPartySystemInfoSubst
19:08:56 <anteaya> #link https://wiki.openstack.org/wiki/Template:ProgramsThirdPartySubst
19:09:13 <jesusaurus> o/
19:09:14 <anteaya> so the first one is the one we looked at last week, for third party accounts
19:09:27 <anteaya> the second one is new, meant for openstack programs
19:09:49 <anteaya> if we are happy, I can get krtaylor to fill out one for third party
19:09:58 <jeblair> anteaya: cool.  most of that looks good.  i'd suggest removing the mission statement as it's sort of duplicative
19:10:01 <anteaya> and perhaps jeblair will fill out one for infra
19:10:06 <anteaya> as a seed for others
19:10:13 <jeblair> anteaya: nope, we're not a third party :)
19:10:17 <anteaya> I can remove the mission statement
19:10:19 <fungi> yeah, i think we discussed having the mission statement just replaced by a link to the program page
19:10:24 <anteaya> we are an openstack program though
19:10:27 <jeblair> fungi: ++
19:10:35 <anteaya> which is what the second template is for
19:11:24 <jeblair> anteaya: ah, i see; though we have no third-party testing related to our program... i'm not sure it makes sense to have this for every program, but rather just for those that have 3rd party testing
19:11:28 <fungi> anteaya: one question though, what is the intended workflow here for third-party systems which are dedicated to only testing stackforge projects (you don't have to know the answer now, just worth thinking about--there are more than a few)
19:11:48 <anteaya> right, I we do have a relationship with thrid party though
19:12:13 <anteaya> in taht we oversee the struture and have a direct say in how that structure is built and managed
19:12:47 <anteaya> fungi: I don't know, I don't know how stackforge testing would differ from testing openstack projects
19:12:58 <anteaya> I would need to talk to some maintainers of such an account
19:12:59 <jeblair> anteaya: sure, but i don't think we have the kind of relationship that i see this page being used for
19:13:05 <anteaya> okay
19:13:16 <anteaya> I'll work with neutron to make a seed page
19:14:02 <anteaya> any other comments/corrections on these templates?
19:14:16 <anteaya> I can work to have the seed pages up for review next week
19:14:26 <jeblair> anteaya: lgtm, and thanks again!
19:14:29 <anteaya> great
19:14:31 <anteaya> thanks
19:14:58 * ttx lurks
19:15:15 <jeblair> #topic  Formatting Automated Gerrit Account Names (anteaya)
19:15:25 <anteaya> me again
19:15:30 <anteaya> #link https://etherpad.openstack.org/p/automated-gerrit-account-naming-format
19:15:53 <anteaya> so I have dumped what I have found about gerrit account names for automated accounts
19:16:03 <anteaya> we discussed some keywords last week
19:16:17 <anteaya> I need some more agressive guidance on how to seperate the groups
19:16:28 <anteaya> and then to id which ones need to be renamed
19:16:37 <anteaya> and then what process to rename
19:17:08 <jeblair> anteaya: anything that votes (or is intended to eventually vote) in the verified colum is "{name} CI"
19:17:19 <anteaya> great
19:17:20 <jeblair> anteaya: anything else automated is "{name} Bot"
19:17:25 <anteaya> that helps
19:17:37 <anteaya> okay so when we look at {name}
19:17:41 <anteaya> what are the options?
19:17:45 <SergeyLukjanov> ++ for CI/Bot naming
19:18:01 <SergeyLukjanov> anteaya, there are company names and project names
19:18:02 <anteaya> we have a group that needs 4 cinder ci accounts
19:18:10 <anteaya> that can get long
19:18:17 <SergeyLukjanov> anteaya, we have sahara-ci (honestly it's still savanna-ci)
19:18:24 <anteaya> you do
19:18:25 <jeblair> anteaya: i think most of those pass the sniff test; they seem fairly descriptive
19:18:36 <anteaya> okay so we can grandfather these
19:18:50 <jeblair> anteaya: oh, well, i think many of them should change
19:18:51 <fungi> seems fine, then anyone wanting to filter all automated systems can just match on " (CI|Bot)$" in names i suppose
19:18:57 <clarkb> fungi: yup
19:19:16 <clarkb> jeblair: just the descriptive name or the username too?
19:19:17 <anteaya> jeblair: many of the existing ones on the list should change?
19:19:20 <SergeyLukjanov> fungi, it'll be useful I hope
19:19:20 <jeblair> anteaya: i think we should be looking for something like "{company} {product} CI"
19:19:28 <anteaya> jeblair: great
19:19:42 <jeblair> anteaya: or "{product} CI" or "{company} CI" if they are, er, a less diverse company.  :)
19:19:45 <fungi> i also think getting rid of "openstack" in third-party ci/bot names is advisable (i try to trim that out when i'm the one handling requests)
19:19:57 <SergeyLukjanov> fungi, ++
19:19:58 <jeblair> fungi: ++
19:20:00 <anteaya> yes, I agree that only we should be using openstack
19:20:14 <fungi> but i do see some in the list, so they ought to get cleaned up in this process
19:20:19 <anteaya> let me come up with a list of suggested revisions for the list for next week
19:20:22 <SergeyLukjanov> and we need to rename it to openstack-ci (OpenStack CI)
19:20:56 <clarkb> do we plan on updating name and username?
19:21:01 <clarkb> or just the descriptive name?
19:21:17 <anteaya> I think everything
19:21:29 <anteaya> part of the issue is that name and username don't match
19:21:32 <clarkb> https://review.openstack.org/Documentation/cmd-set-account.html won't update the username
19:21:34 <anteaya> like brocade
19:21:38 <clarkb> so username will require DB changes
19:21:44 <clarkb> anteaya: ok
19:21:53 <anteaya> we have brocade_jenkins and brocade_tempest for teh same account
19:21:58 <anteaya> that is just confusing
19:22:20 <anteaya> yes, that will be a step during the process of changing the names
19:22:25 <anteaya> editing the db
19:22:26 <fungi> i don't think the usernames matter
19:22:42 <anteaya> I would like them to be consistent
19:22:57 <fungi> they aren't displayed in the webui with their votes, and changing them instantly breaks teh remote systems which were logging in with them
19:23:05 <anteaya> so if someone asks me about brocade_jenkins I know what account they are talking about
19:23:07 <fungi> which is a mighty steep price for consistency
19:23:15 <clarkb> fungi: good point
19:23:36 <fungi> gerrit already makes sure they're unique, so i think that should be sufficient
19:23:49 <anteaya> do we have any control over how they set their usernames?
19:24:05 <SergeyLukjanov> personally I'd like to see username-displayedname consistence, but price - break all 3rd party, edit db manually
19:24:07 <anteaya> so that at the very least in future the usernames and account names can match up?
19:24:24 <fungi> we can assign them in the future
19:24:32 <anteaya> great
19:24:36 <anteaya> I can settle for that
19:24:37 <fungi> just need to make sure that's part of the process
19:24:41 * anteaya nods
19:24:46 <SergeyLukjanov> could we always resolve username to display name?
19:25:00 <fungi> there are gerrit api calls which can do that
19:25:03 <fungi> i believe
19:25:08 <SergeyLukjanov> like russellb's reviewstats shows usernames
19:25:14 <anteaya> did
19:25:20 <anteaya> reviewstats is offline
19:25:44 <anteaya> I think I have enough to work on this and come back next week with some suggestions
19:25:48 <anteaya> thanks
19:25:48 <russellb> not sure it's worth publishing anymore, fine if people want to run locally, but stackalytics has a better UI anyway
19:25:48 <clarkb> https://review.openstack.org/Documentation/rest-api-accounts.html#get-account yup
19:26:05 <anteaya> russellb: I liked yours better
19:26:16 <SergeyLukjanov> clarkb, thanks
19:26:27 <jeblair> russellb: i use it; i find examining disagreements to be important
19:26:29 <SergeyLukjanov> so, we should have no issues with it
19:26:36 <russellb> you guys seen http://stackalytics.com/report/contribution/nova-group/30 ?
19:27:06 <clarkb> russellb: there isn't anythin like that for infra last I looked
19:27:14 <clarkb> (probably does exist it just isn't navigable)
19:27:18 <anteaya> russellb: I hadn't before, I still like yours better, simpler and I like text
19:27:21 <russellb> clarkb: http://stackalytics.com/report/contribution/infra-group/30
19:27:34 <pleia2> I had chatted with anteaya a couple weeks ago about hosting it somewhere in infra
19:27:35 <jeblair> russellb: nice; though i actually have reviewstats _output_ the disagreements so i can read them; and i also make lots of ad-hoc groups.
19:27:45 <russellb> ah, cool
19:27:57 <pleia2> then other things came up, I think I was supposed to follow up with russellb to see if he wanted us to ;)
19:28:02 <russellb> well i can fix the hosted stats if enough people really care ... I think it may be something with the upgrade, i dunno, i haven't messed with it
19:28:12 <mordred_phone> jeblair: we could likely get stackaltics to do that too
19:28:13 <russellb> +100000 to hosting it in infra
19:28:15 <russellb> plz
19:28:21 <russellb> if people want it
19:28:25 <jeblair> anteaya: so i think that's it for the account name topic
19:28:27 <jeblair> ?
19:28:28 <russellb> just never got around to doing the work to get it hosted myself
19:28:33 <anteaya> jeblair: yes
19:28:34 <pleia2> russellb: cool
19:28:44 <jeblair> i think the horizon repo topic is left over from last week
19:28:47 <jeblair> so next up
19:28:52 <jeblair> #topic  Release git-review 1.24
19:28:55 <jeblair> i don't know who added that
19:29:10 <jeblair> i'm not sure if it was intended as an imperative
19:29:18 <clarkb> jeblair: do it now ! :P
19:29:21 <ttx> yes!
19:29:21 <jeblair> like, adding it to the wiki page will cause it to happen
19:29:25 <clarkb> I am on board with a release
19:29:39 * ttx hacks up a irc-to-tag script
19:29:45 <clarkb> does the https functionality have feature parity ish with ssh now?
19:29:47 <jeblair> fungi: ?
19:29:48 <anteaya> ha ha ha
19:30:02 <jeblair> ttx: wiki -> irc -> tag
19:30:04 <clarkb> I think that is the one item that may be nice to have in before doing a release but it isn't critical either
19:30:05 <fungi> yep, i'll go ahead and cut one. did we want to get the -W option reviewed and merged for 1.24 as well?
19:30:24 <clarkb> fungi: there was enough commenting on that chnage that I didn't expect it to merge quickly
19:30:27 <fungi> i think i added it and maybe forgot to add (fungi) on the line
19:30:31 <clarkb> but I didn't look at it after the first patch
19:30:35 <ttx> jeblair: as soon as I'm finished with my IRC actions -> RememberTheMilk gateway
19:30:45 <fungi> i was letting the dust settle on it but need to revisit
19:31:12 * ttx looks forward to not having to ad LANG=C every time he uses git-review
19:31:25 <anteaya> fungi added it: https://wiki.openstack.org/w/index.php?title=Meetings/InfraTeamMeeting&diff=prev&oldid=53841
19:31:28 <mordred_phone> ttx speak moar english
19:31:46 <jeblair> fungi: is the '-W' option an openstackism?
19:31:56 <fungi> anteaya: yeah, i remember adding it, was just admonishing myself for forgetting the nick tagline
19:31:58 <ttx> mordred: I realized in Jerusalem that French should be attempted first
19:32:03 <anteaya> fungi: ah
19:32:20 <clarkb> jeblair: yes
19:32:23 <mordred_phone> jeblair: yah.
19:32:26 <fungi> jeblair: good point, it's for setting workflow +1 and its docs mention it only works with a gerrit configured for that label
19:32:27 <jeblair> clarkb: :(
19:32:35 <fungi> er, workflow -1
19:32:49 <jeblair> would be neat if that could be generalized, but i don't have any _good_ ideas off the top of my head for that
19:32:57 <fungi> yeah, i'll see if any spring to mind
19:33:01 <clarkb> jeblair: maybe a .gitreview value to set on -W
19:33:24 <fungi> possibly, followed by a mass patchbomb to all projects in our gerrit
19:33:25 <jeblair> clarkb: heh, that's going to be a fun 297 patches to merge
19:33:33 <fungi> i can take that up
19:33:43 <clarkb> or make it default to what we do
19:33:49 <clarkb> and let others override that way
19:33:51 <fungi> that would then be an openstackism
19:34:06 <fungi> i'm more in favor of having it default to off
19:34:14 <fungi> anyway, that can be taken up in the review
19:34:18 <fungi> no need to waste meeting time on it
19:34:22 <jeblair> i mean "git review --label='Work In Progress'" works but isn't exactly convenient.
19:34:30 <jeblair> fungi: true.
19:34:49 <SergeyLukjanov> config file for WIP label?
19:34:52 <jeblair> fungi: so, maybe cut 1.24 without wip?
19:34:56 <jeblair> to make ttx happy
19:34:58 <fungi> jeblair: yeah, i think so
19:35:00 <SergeyLukjanov> jeblair, ++
19:35:09 <SergeyLukjanov> not only ttx :)
19:35:17 <fungi> wip can be considered for 1.25
19:35:23 <jeblair> SergeyLukjanov: ;)
19:35:32 <jeblair> sounds good
19:35:34 <jeblair> #topic  Fedora/Centos7 Plans (ianw)
19:35:35 <fungi> i've been using current master long enough i'm pretty sure it's sane (plus, we do have some testing on it as well)
19:35:51 <ianw> hi, so the f20 job for devstack has been pretty reliable
19:36:07 <ianw> so i'm looking at getting it on the path to voting
19:36:16 <ianw> the first thing is getting it in multiple clouds
19:36:39 <jeblair> was the issue that hpcloud didn't have a base image?
19:36:43 <ianw> are we fully moved to the new hp cloud that has f20 images?
19:36:55 <clarkb> hpcloud only has f17 iirc
19:36:56 <fungi> ianw: we are
19:37:02 <clarkb> even in 1.1
19:37:08 <fungi> oh?!?
19:37:10 <fungi> eek
19:37:22 <jeblair> | 831fa6a5-1ca5-42ea-bd41-4cbebf01085a | Fedora 20 Server 64-bit 20140407 - Partner Image                                   | ACTIVE |
19:37:28 <jesusaurus> clarkb: theres a partner image
19:37:30 <clarkb> ah another partner image
19:37:30 * anteaya has lost power once already, it could happen again anytime
19:38:10 <jeblair> so most of our "run on new image" work is waiting on dib/glance in nodepool
19:38:19 <jeblair> but since we already have this working on f20...
19:38:29 <jeblair> i don't see a reason for this work to block on that.
19:38:37 <clarkb> yup the unbound change to make dib work needs approval I had planned on doing that today but we are still underwater on the zuul/nodepool stuff
19:38:43 <clarkb> jeblair: wfm
19:38:47 <ianw> that's my next question; what is the status of the dib work?
19:39:08 <fungi> ianw: increasing review priority for me this week, assuming nodepool settles down for us
19:39:14 <clarkb> ianw: there are patches up for review. We need a small change to puppet which is ready for approval we just need time
19:39:23 <clarkb> ianw: then its on to reviewing the changes that actually marry dib and nodepool
19:39:45 <jeblair> is there a nodepool glance change yet?
19:39:55 <clarkb> mordred_phone: ^
19:39:55 <ianw> clarkb: ok, i might ping you outside meeting time to get fully up to speed
19:40:31 <ianw> so the other thing, thinking forward to centos7 release, i think that's going to be the best long-term base for rpm testing
19:40:41 <bcrochet> +1
19:40:47 * jeblair assumes mordred's seatback and tray tables are in the upright position
19:40:48 <ianw> presumably, the dib work will be the way to deploy centos7?
19:40:48 <fungi> ianw: any eta on that upstream?
19:41:07 <clarkb> ianw: yes I would expect to do trusty and centos7 via dib
19:41:19 <ianw> fungi: i think "soon"
19:41:31 <fungi> rsn... got it
19:41:45 <jeblair> fungi: what was your question?
19:42:10 <fungi> jeblair: i was wondering when centos 7 was due for release
19:42:13 <jesusaurus> is centos7 going to be used for infra, or just for testing? should i add a puppet-apply test for f20 and/or centos7?
19:42:16 <jeblair> fungi: ah, gotcha
19:42:43 <jeblair> jesusaurus: i think we will be in no hurry to move our centos6 servers to 7
19:42:48 <clarkb> jeblair: we will likely only use fedora for testing never for infra
19:42:55 <clarkb> er jesusaurus ^
19:42:55 <fungi> jesusaurus: i expect we would be likely to use it in places where we need it, but yeah, no need to upgrade just for the sake of it
19:43:04 <jesusaurus> gotcha
19:43:05 <clarkb> so the value of testing on fedora 20 is minimal when it comes to that test
19:43:15 <ianw> so, in conclusion, i should test out the hp f20 partner image with the idea of bringing it it into nodepool?
19:43:24 <jeblair> ianw: i think so
19:43:36 <clarkb> yup run the build scripts on it and see if it looks happy
19:43:40 <clarkb> then we can add the image to nodepool
19:44:01 <jeblair> centos7 should probably wait for the dib stuff to land (and, also, centos7)
19:44:04 <ianw> and i will reach out to clarkb about the dib work and that will be the base for centos7
19:44:15 <clarkb> ianw: sounds good
19:44:52 <ianw> jeblair: yeah, just want to be as ready as possible when it does land :)
19:45:01 <ianw> ok, thanks, no more on that topic from me
19:45:06 <jeblair> ianw: cool, thanks!
19:45:11 <jeblair> #topic  Consistency in acl reviews (anteaya)
19:45:21 <anteaya> #link https://review.openstack.org/#/q/owner:%22Dan+Bode%22+file:%255E.*/acls/.*+NOT+status:abandoned,n,z
19:45:33 <anteaya> apologies in advance if I lose power again
19:45:45 <anteaya> so I would like to review the reviewing of this set of patchs
19:45:53 <anteaya> specifically the acl file reviews
19:46:12 <anteaya> going back of these I realize I was inconsistent, so I need to address that and be more consistent
19:46:18 <anteaya> but the part I wanted to discuss
19:46:29 <anteaya> and I do wish sdague and zaro were here
19:46:59 <anteaya> is that on one of the patches, dan got -1'd for editing the file the way I had asked him to edit
19:47:08 <anteaya> which I find embarassing, personally
19:47:21 <anteaya> he got -1'd twice
19:47:24 <zaro> here.  sorry i forgot about meeting.
19:47:31 <clarkb> I don't think it is embarrasing. It is definitely inefficient.
19:47:45 <clarkb> we can hash out these disagreements without makeing the author go back and forth
19:47:52 <anteaya> agreed
19:47:55 <jeblair> anteaya: it definitely wasn't due to a lack of accurate reviewing on your part; it was because the actual issue is very unclear
19:48:07 <anteaya> if I am reviewing a file poorly, I would like to know and to improve
19:48:14 <anteaya> great
19:48:21 <anteaya> let's see if we can get some clarity
19:48:26 <anteaya> two things I saw
19:48:41 <anteaya> require contributor agreement = true
19:48:50 <anteaya> and the [project] stanza
19:49:00 * anteaya notes the howling wind outside
19:49:09 <anteaya> anyone with any thoughts?
19:49:19 <jeblair> in order to avoid wild swings on the CLA issue, i think we should avoid trying to decide it ourselves early...
19:49:29 <anteaya> jeblair: I agree
19:49:37 <jeblair> it's an unanswered legal and policy question, and will likely be so for quite some time
19:49:37 <anteaya> what should we do for now?
19:49:50 <fungi> long ago i stopped -1'ing patches for cruft where people are cargo-culting no-op default values
19:50:15 <jeblair> so i think the approach of not changing our existing projects, and also not requiring the cla for projects that are split from projects that don't require the cla is the closest thing we have to keeping the 'status quo'
19:50:28 <clarkb> ++
19:50:43 <anteaya> okay, so in this case referencing config.config since that is the parent acl of this change series
19:50:47 <anteaya> I can follow that
19:50:48 <fungi> that's basically what i've done as well
19:51:09 <anteaya> I will do that too, or ask if I can't figure out the parent
19:51:15 <anteaya> is [project] cruft?
19:51:20 <anteaya> I had thought it is
19:51:56 <fungi> i'm not sure i understand your question
19:52:13 <clarkb> the active = true bit is
19:52:13 <anteaya> in the acl file, the [project] stanza
19:52:23 <anteaya> https://review.openstack.org/#/c/96522/5/modules/openstack_project/files/gerrit/acls/openstack-infra/puppet-pip.config
19:52:23 <clarkb> or is it status = active
19:52:26 <clarkb> whatever that line is
19:52:30 <anteaya> status = active
19:52:34 <jeblair> anteaya: it's not necessary, certainly.  i think fungi was saying that it doesn't matter either way, so no use going back and doing another patchset about it
19:52:36 <clarkb> but it doesn't hurt to have it either and is probably not worth a -1
19:52:51 <jeblair> anteaya: what we might want to do is remove all refs from our docs and then merge a patch that removes it from all acl files
19:52:52 <SergeyLukjanov> clarkb ++
19:52:54 <anteaya> okay, I will ignore it then if it is in the file
19:52:57 <jeblair> anteaya: then we might stop the cargo culting
19:53:00 <fungi> right, i need to update my current cleanup patch series, but i think it's something we solve by fixing all the existing acls in one go so people stop copying around unnecessary stuff
19:53:12 <jeblair> fungi: oh you've already started on that :)
19:53:13 <clarkb> fungi: agreed
19:53:21 <clarkb> jeblair: yup there is a series of WIP changes
19:53:22 <fungi> i've already git it basically scripted
19:53:28 <anteaya> okay, so I will ignore it for now if it is there
19:53:30 <SergeyLukjanov> I'm still thinking on yaml-based acls, hope to publish spec someday
19:53:44 <fungi> to make it repeatable and better able to weather rebase hell or race conditions in reviewing existing changes
19:53:50 <anteaya> I don't usually suggest the refs/tags/* line in a file that doesn't have it
19:54:04 <anteaya> I figure if people want tags they will know to include it
19:54:42 <SergeyLukjanov> I'm trying to suggest tags or smth else when see that folks most probably would like to have it
19:54:51 <fungi> our documentation should suggest reasonable things, and then we should spot when something is required to be added to the acl by implication from jobs they may be adding or similar evio\dence
19:54:53 <fungi> evidence
19:55:25 <anteaya> maybe I need to know more about tags then
19:55:27 <clarkb> fungi: I think a large problem is a lot of people doing this have zero experience with our infra and gerrit
19:55:34 <anteaya> clarkb: +
19:55:54 <clarkb> they are told to stackforge or do $thing with openstack and really don't grok what they need
19:56:13 <clarkb> so suggestions may help that
19:56:20 <fungi> right. if a project is adding release jobs but has no tag section in their acl for example, then it might merit mentioning (to find out if they really meant to add the jobs, or require the acl addition)
19:56:25 <clarkb> maybe a "So you wanna stackforge" doc
19:56:48 <jeblair> clarkb: the existing stackforge doc could be expanded
19:56:56 <clarkb> jeblair: ya
19:57:28 <jeblair> #topic  Open discussion
19:57:34 <jeblair> #link https://wiki.openstack.org/wiki/Qa_Infra_Meetup_2014
19:57:45 <jeblair> for anyone going to the meetup, could you please sign up on that page ^
19:57:55 * SergeyLukjanov remembering the time when I've proposed the sahara addition to stackforge CR
19:58:24 <pleia2> I have the "not quite production" zanata puppet files from Carlos, will be looking through them and hope to have some kind of maintainability report by next meeting (if you've been following the thread on list, it's kind of tricky)
19:59:05 <jeblair> pleia2: i'm sort of surprised.  i guess at the summit they didn't realize we run free software here?
19:59:28 <pleia2> jeblair: redhat does all kinds of open source, you just need a license for delivery and updates ;)
19:59:40 <pleia2> sorry, that's probably inapproprite, I'm just frustrated
19:59:52 <clarkb> :(
20:00:02 <zaro> had a question about private gerrit for security reviews bug 1083101
20:00:03 <uvirtbot> Launchpad bug 1083101 in openstack-ci "Set up private gerrit for security reviews" [High,In progress] https://launchpad.net/bugs/1083101
20:00:09 <jeblair> pleia2: if we can't run it, pootle still seemed like a good option; the delta between it and zanata was small, and we have people who might actually hack on it.
20:00:21 <zaro> do we want to continue to make that happen?
20:00:30 <pleia2> jeblair: noted, I'll see how far I get this week we'll go from there
20:00:42 <fungi> zaro: oh, right, i asked the rest of the vmt. it's still desirable for us
20:00:47 <jeblair> i'm out next week, i'll be completely unreachable
20:00:48 <Ajaeger> pleia2, your work on a transifex replacement is appreciated. Just heard today some comments that transifex has some problems - we might have lost some translations ;(
20:00:49 <ttx> +1
20:01:14 <jeblair> and i think we're at time
20:01:16 <jeblair> #endmeeting