15:00:21 <fungi> #startmeeting tc
15:00:24 <openstack> Meeting started Thu Jun 21 15:00:21 2018 UTC and is due to finish in 60 minutes.  The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:25 <cdent> tc-members let's assemble
15:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:27 <openstack> The meeting name has been set to 'tc'
15:00:29 <fungi> #topic Office Hour
15:00:37 <fungi> #chair ttx cdent
15:00:38 <openstack> Current chairs: cdent fungi ttx
15:00:39 <smcginnis> o/
15:00:44 <fungi> #chair smcginnis
15:00:44 <openstack> Current chairs: cdent fungi smcginnis ttx
15:01:16 <mnaser> o/
15:01:29 <cdent> #chair mnaser
15:01:30 <openstack> Current chairs: cdent fungi mnaser smcginnis ttx
15:01:47 <dhellmann> o/
15:01:59 <cdent> #chair dhellmann
15:02:04 <openstack> Current chairs: cdent dhellmann fungi mnaser smcginnis ttx
15:02:07 <smcginnis> Maybe we need a standard single #chair line we can paste for the whole TC. :D
15:02:14 <cdent> this is more fun somehow
15:02:23 <cdent> because of all the pinging
15:02:30 <smcginnis> ;)
15:02:34 <fungi> heh
15:02:40 <cmurphy> o/
15:02:40 <dhellmann> we could make it a chain. each person who is chaired has to chair the next in line
15:02:48 <dhellmann> it's like saying hello :-)
15:02:49 <cdent> zaneb: you around? Is adjutant a topic we need to hash today?
15:02:51 <fungi> go for it
15:02:58 <dhellmann> oh, that's me
15:03:03 <dhellmann> #chair cmurphy
15:03:04 <openstack> Current chairs: cdent cmurphy dhellmann fungi mnaser smcginnis ttx
15:03:18 <fungi> we're up to 7 out of 13, not bad
15:04:02 <dhellmann> how are folks doing with their liaison outreach? has anyone had trouble reaching a team's PTL?
15:04:16 <smcginnis> I have not gotten there yet. :/
15:04:29 * cmurphy hasn't started yet
15:04:29 <mnaser> i need to follow up on mine but i'm starting to feel a weird possible conflict of interest on projects im directly involved in
15:04:30 <smcginnis> Should be able to do that today. Or at least get started on it.
15:04:31 <fungi> anybody who wants to weigh in on the castellan base service addition thread revival from yesterday, please do
15:04:41 <mnaser> feeling like i might be biased in my opinion in a way
15:05:03 <smcginnis> mnaser: On the other hand, you have a really good feel for the state of the project.
15:05:03 <mnaser> my plan is to hash it out with who i'm paired with to say "this is what i see, if you see it different, please let me know"
15:05:07 <ttx> Did two, went well and was appreciated i think
15:05:12 <dhellmann> mnaser : that's a good insight, and it's part of why I wanted 2 people on each project.
15:05:25 <ttx> dhellmann: any opinion on my traffic lights icons ?
15:05:41 <johnsom> Are there more questions about Octavia's support of both Barbican and Castellan?
15:05:45 <dhellmann> ttx: I like those. I mean to ask if you were thinking of putting them in the table, or just in the summaries?
15:06:22 <ttx> I was thinking just in summaries, as a business summary
15:06:29 <dhellmann> wfm
15:06:34 <ttx> I don't want it to turn into yet another badge
15:06:41 <dhellmann> yeah, good point
15:06:53 <ttx> and I feel like a table at the top would... facilitate that
15:06:55 <dims> o/
15:07:00 <mnaser> #chair dims
15:07:00 <openstack> Current chairs: cdent cmurphy dhellmann dims fungi mnaser smcginnis ttx
15:07:23 <mnaser> yeah i feel health being a tag would be problematic for the growth of the project and general morale
15:07:37 <ttx> dhellmann: I was wondering what would be the color of Requirements after your check
15:07:39 <smcginnis> Agree
15:07:59 <ttx> needing urgent action (red) or just a warning (orange) ?
15:08:04 <mnaser> it's already hard enough going through a rough time in a project, even worse for morale if you have a red "this team is a problem"
15:08:21 <ttx> To be fair, I don't see red as a satin, could be that we need to add it to the help list
15:08:26 <ttx> stain*
15:08:31 <dhellmann> ttx: very dark orange? :-)
15:08:39 <smcginnis> Burnt umber
15:08:44 <mnaser> i love that we work in the open but sometimes i feel if that health tracker page was private to tc, it might avoid teams feeling like they are "the problem"
15:08:53 <ttx> Basically if the team requires further work from eth TC, I'd put red
15:08:57 <mnaser> (recalling nova team discussion)
15:09:05 <ttx> like if you create a storyboard entry about it, then red
15:09:23 <ttx> orange is like... we need to pay some attention
15:09:26 <mnaser> *only* if the team asks for it too imho (im assuming thats what you mean)
15:09:27 <dhellmann> mnaser : yeah, I've been trying to focus on identifying areas where we can help, rather than looking at it as anything (or anyone) failing
15:09:52 <dhellmann> ttx: that seems like a good way to draw the distinction
15:09:55 <ttx> mnaser: yeah, we had a discussion about it with cdent... Hard to balance
15:09:59 <fungi> i worry that the traffic lights, like many things we do, will be seen as implying something more and some teams will either object to getting a red/yellow light or pressure to get a green purely for reasons of perception
15:10:24 <ttx> fungi: I'm happy retiring them once they start being a bit too... public
15:10:31 <ttx> It's just a convenient shortcut
15:11:19 <fungi> but yeah, it's too early to know for sure how any of them will take it
15:11:43 * ttx adds a "concern"
15:11:56 <mnaser> the OSA team overall is going through a really hard time right now
15:12:26 <mnaser> PTL changed employer, isnt as involved with openstack as he can, many of current cores are not directly employed to do OSA work, it's just a small part of what they do so contributions+reviews are down
15:12:36 <mnaser> but there is a huge user base and more and more people wanting/needing to use it
15:12:48 * mnaser feels this is a very common issue with deployment projects
15:12:52 <dhellmann> that feels like exactly the sort of thing we need to know about, for exactly the reason that there are so many users
15:13:32 <mnaser> i've been doing a lot of work trying to unbreak gates and improve testing but struggles have been just getting enough reviews to merge code, it comes in bursts or so, as cores have free time here and tehre
15:15:06 <mnaser> meeting participation is significantly down too, so yeah, it's a bit rough on that side of things.  but i hope i'm not just taking all the attention on one project :)
15:15:51 <cdent> I would expect most of that is common to a lot of projects, especially deployment-related ones, as you say, but also plenty of others. telemetry is a bit like that
15:16:29 <dhellmann> yes, I suspect that's going to be something we see for several teaems
15:16:37 <dhellmann> the requirements team is in the same state
15:17:05 <mnaser> it seems to me that the projects that help the underlying infrastructure to support the ecosystem struggle usually
15:17:07 <dhellmann> murano, to some degree as well
15:17:08 <mnaser> requirements, deployment projects
15:17:31 <fungi> it's not just a problem for deployment projects in openstack either. the configuration management and orchestration landscape is constantly changing, and there have been and will be some that die a slow death of attrition (not saying that's happening to ansible right now)
15:18:12 <mnaser> fungi: right, but ansible is (in my opinion) the 'hotness' and it's struggling
15:18:25 <fungi> but as much as we need to help shore up projects which are struggling to get contributors, i think there will be times when we also have to let things die
15:18:34 <dhellmann> that observation came up in one of the upgrade sessions at the forum, too, when we were talking about the split between using home-grown tools and community-provided tools
15:18:52 <fungi> mnaser: i agree, ansible lacking a groundswell of support in openstack seems anomalous
15:18:53 <mnaser> i totally agree, we have to let go of somethings at some point
15:19:30 <mnaser> dhellmann: what i am seeing (from a 'commercial' pov) is a lot of users who built on home grown tools wanting to migrate on community provided tools
15:19:41 <mnaser> which is super super cool and hopefully brings more contributions
15:19:43 <smcginnis> mnaser: I've seen that as well.
15:20:05 <dhellmann> yes, that will work out well, if it includes the collaboration aspect of open source and doesn't focus so much on the "someone else is doing it for me for free" aspect
15:20:21 <mnaser> i personally love the gerrit workflow but sometimes i really do wonder if that's a barrier to submitting code and pushing changes up.
15:20:34 <mnaser> we see a lot of bug reports in OSA that say "this is what i changed and it fixed it" but no patch
15:20:50 <fungi> tag with low-hanging-fruit
15:21:24 <mnaser> right, but in the bigger picture, i really do wonder if our choice of tooling makes it harder for new contributors
15:21:43 <mnaser> for example, i've never submitted a linux kernel patch, because i am terrified and super confused on how to do the whole process... and i've done dev work for a while.
15:22:23 <cdent> It's definitely a worthwhile topic. Our workflow is a learning curve, and learning curves are not friendly to casual-ness
15:22:48 <mnaser> and maybe we're no longer in a position where we can be picky and say 'you have to play by our rules to develop with us'
15:23:07 <mnaser> it could work when we were the hot thing but as things slow down a little bit, it becomes much more of a hassle rather than anything
15:23:11 <dhellmann> do you have some specific alternatives in mind?
15:23:55 <dhellmann> I'm reluctant to optimize the entire toolchain for casual contributors, but improving the casual contributor workflow does seem like something we should pursue
15:24:19 <mnaser> i hate to say it, i don't like their workflow, i don't like that it's a business/commercial type of offering, but github seems to be a solid place that contains a large base of existing developers that might help gather new users
15:24:21 <fungi> part of the "problem" there is that code review is also not friendly to casual-ness, regardless of the tooling
15:24:35 <dhellmann> mnaser : is the problem "git" or "gerrit"?
15:24:47 <dhellmann> fungi : yeah, that's true
15:24:48 <cmurphy> mnaser: the way you frame that makes it sound like our workflow was an arbitrary choice, and it's not
15:24:54 <fungi> i think the problem is having standards and holding code submissions to those standards
15:25:03 <mnaser> i think gerrit.  it's too specific and tied into our own little ecosystem
15:25:07 <fungi> depending on how you want to define "problem"
15:25:15 <mnaser> maybe we should find a way to allow users to login via github and automatically import their keys to gerrit?
15:25:16 <smcginnis> Please no github PRs.
15:25:26 <mnaser> at least it's just a login and git review ..
15:25:36 * fungi objects to use of "little" and would similarly characterize github users as "small-minded"
15:25:50 <dhellmann> mnaser : that sounds interesting. I also had the idea a while back to have the bot that closes github PRs turn them into gerrit requests instead.
15:26:09 <smcginnis> dhellmann: Was just thinking that through.
15:26:12 <mnaser> rather than go, setup a launchpad account (potentially that you never used before), login to gerrit, go manually add your keys, install git-review, commit, `git review`
15:26:13 <ttx> Unrelated news: to establish a baseline mnaser and I did an org diversity analysis and posted it at https://etherpad.openstack.org/p/rocky-2-org-diversity
15:26:25 <smcginnis> The trick would be creating gerrit accounts automatically for the github users.
15:26:34 * jroll points out http://gerrithub.io/
15:26:40 <mnaser> MAYBE if you can login to gerrit via github directly, and have your keys automatically import, it would make things a lot simpler?
15:26:42 <jroll> notably "Keep in touch with external users synchronizing pull requests with reviews."
15:26:42 <clarkb> gerrithub is terrible imo
15:26:49 <jroll> I haven't used it, fwiw
15:26:50 <clarkb> they completely nuked jenkins a few years back
15:26:56 <ttx> In bold are the ones that should have their diversity tags changed, if we don't change anything
15:26:59 <clarkb> and jenkins had to get github to restore from backup
15:27:06 <mnaser> lol ^
15:27:07 <fungi> there's not much of a technical hurdle in turning github prs into gerrit changes. the disconnect is an entirely human one. the patch submitters aren't going to find or follow up on feedback (and i'd argue that even if we worked entirely on github the problem would be similar)
15:27:33 <dtroyer> [jumping in a bit late] having just helped a bunch of new folk get set up to contribute via Gerrit, I was reminded of how much of a process it is.  But it wasn't as much of a problem as I feared.  I think part of that was there were groups of co-located people who could help each other get it done
15:27:33 <ttx> They are roughly ordered in levels of diversity, the idea being to track evolution rather than binary tags
15:27:33 <mnaser> what about: login via github to gerrit and ssh keys automatically get imported?  that's probably a whole bunch of extra work done
15:28:02 <fungi> and then there's the legal hurdle. we can't force submissions on github to come from people who have agreed to the icla, nor can we sync them up to foundation accounts for tracking ccla addendums once we switch to enforcing the dco
15:28:10 <dhellmann> dtroyer : having a group going through the process together certainly helped me, back in the day
15:28:20 <mnaser> fungi: yes, that is awful and super horrible ux unfortunately
15:28:31 <mnaser> i had to on-board someone and i was confused for a while why 'git review' would keep rejecting commits
15:28:37 <mnaser> until i ran it with -vvv and i got the icla warning
15:28:59 <dhellmann> ttx: thanks for preparing that info
15:29:24 <mnaser> LF projects complain in the git review message about 'missing signed-off-by' .. maybe we can at least look into adding that to the error message that appears without having to make it show up when you do -vvv
15:29:29 <smcginnis> Hmm, stackalytics appears to be broken.
15:29:38 <clarkb> mnaser: aiui you get a message if using current git review
15:29:46 <clarkb> mnaser: it actually comes from gerrit
15:29:48 <fungi> mnaser: also, looking through your list of things to do to set up your gerrit account, i'm reminded of having to do precisely the same sorts of steps to be able to push things to github, and to bitbucket, and to other communities various communities' code submission systems (phabricator, et cetera)
15:29:55 <ttx> smcginnis: indeed, I wanted to refine the stats this morning to prepare for this and failed
15:29:55 <clarkb> (we can test that and confirm)
15:30:04 <mnaser> brew install git; brew install git-review .. just yesterday, it was flat out 'refusing it'
15:30:08 <mnaser> but could be different versions
15:30:09 * ttx need to jump off in 10 min
15:30:19 <clarkb> mnaser: what version does brew install?
15:30:24 <dhellmann> fungi , mnaser : getting everyone onto storyboard would let us drop launchpad, which would mean 1 less account to configure
15:30:34 <mnaser> clarkb: git-review: stable 1.26.0 (bottled)
15:30:41 <smcginnis> mnaser: pip install git-review may be more up to date.
15:30:55 <clarkb> mnaser: ok its possible gerrit update broke that passthrough of error messages
15:31:03 <zaneb> o/
15:31:09 <mnaser> #chair zaneb
15:31:10 <openstack> Current chairs: cdent cmurphy dhellmann dims fungi mnaser smcginnis ttx zaneb
15:31:20 <mnaser> clarkb: yeah maybe someone should look into that, it certainly confused me
15:31:35 <mnaser> ttx, smcginnis: maybe infra can try taking over hosting of stackalytics?
15:31:46 <cdent> fungi your argument about things you have to do sign up to other places doesn't really work in my brain: If I'm doing open source dev of any kind I'm probably alrady signed up to those things
15:31:49 <mnaser> i think it's still at mirantis and very much out of our control and things happen to it all the time?
15:32:05 <cdent> github and openstack are not in the same category of thing
15:32:17 <dhellmann> ttx: are the comments like "50.25% top core review %" the reason for a team not having the diversity tag?
15:32:17 <clarkb> cdent: but from a difficulty perspective they ar ethe same
15:32:22 <clarkb> its not more difficult you just have to do it again
15:32:30 <ttx> dhellmann: yes, or worst 'stat'
15:32:31 <fungi> cdent: sure, one is a proprietary cesspool and the other is a software community built on free principles
15:32:31 <clarkb> there is value in not having to do it again
15:32:35 <clarkb> but it isn't more difficult imo
15:32:36 <dhellmann> ttx: ok
15:32:54 <ttx> dhellmann: trying to expose the subjectiveness of the exercise
15:32:59 <cdent> fungi: I'm not disputing _that_. I agree with you on that, but we do need to think in terms of what casual contributors want, which is not the same as "us"
15:33:14 <ttx> dhellmann: given the limited quality of input data :)
15:33:17 <mnaser> fungi: while i 100% stand by the free principles idea, i just worry that it's *might* be affecting our growth
15:33:33 <ttx> mnaser: depends what you call growth :)
15:33:38 <fungi> cdent: i spent years contributing to free software projects, and never had a github account until i needed one to submit fixes to some openstack dependencies. it was somewhere between annoying and nightmarish
15:33:58 <cdent> fungi: you're special right, you realize that, yeah?
15:33:58 <mnaser> ttx: i guess attracting new contributors and making it easier for casual ones to push things up
15:34:08 <cdent> I'm not defending github
15:34:19 <cdent> But nor am I willing to defend how openstack does things.
15:34:22 <fungi> also i think unbounded growth is a big part of the problem. in biology it would be akin to a cancer
15:34:45 <cdent> we've dealt with the growth, now we need to avoid death
15:34:50 <fungi> i'm much in favor of shrinking
15:35:14 <mnaser> i guess for me it feels like we're missing out on a big audience of developers that might want to contribute but feel like it's a lot of work to do something in openstack
15:35:24 <cdent> mnaser++
15:35:40 <cdent> all of my non-openstack tech-friends tell me that all the time
15:35:53 <fungi> i'm not sure why we're looking for an audience. that in itself sounds like failure
15:35:57 <cdent> they feel like you have to join a club and learn the secret handshakes
15:36:20 <cdent> fungi: because we keep saying we need and want casual contributors
15:36:28 <cdent> if we don't, cool.
15:36:47 <mnaser> we're looking for an audience because some projects that can attract a lot of non openstack people (say, i think of openstack-ansible as an example) that can attract a lot of easy and casual contributions for bug fixes
15:36:56 <ttx> contributing to any decently-sized project is complicated, GitHub or not
15:36:58 <fungi> looking for an audience isn't necessarily the same thing as improving our tools and workflows
15:37:14 <ttx> You have things like CLAs
15:37:20 <ttx> a process, rules
15:37:34 <ttx> I'm not sure most of our pain comes from choice of tools
15:37:44 <fungi> i want to make things easier for the people who want to contribute to openstack, not go and try to convince people who have never heard of it that it's some cool new thing they should be working on. that was the hype bubble i'm glad to see finally behind us
15:37:47 <ttx> vs. the learning curve of shared understandings
15:37:59 <ttx> or the CLA signing
15:38:00 <zaneb> as an aside, I really hate it when we talk about casual contributors as if there's a random pool of people out there looking for a project who might contribute to OpenStack as a hobby
15:38:18 <zaneb> IMO what we want is for *people who use OpenStack* to also contribute back
15:38:23 <mnaser> zaneb: i agere
15:38:28 <mnaser> that's what i feel it is
15:38:30 <zaneb> even if it is not their full-time job
15:38:36 <dhellmann> zaneb : that's not what I mean when I say that. I mean people for whom writing software is not their first job, and who are likely users of openstack now.
15:38:41 <cdent> zaneb: that's not what _I_ mean by casual. I mean people who are not magical unicorn openstack devs (like most of us). I mean users of openstack.
15:38:41 <fungi> zaneb: "casual contributors" to me is people deploying openstack in their organization who see a problem and want to fix it
15:38:55 <dhellmann> so contributing a patch is not anywhere close to the top of their priority list
15:38:58 <ttx> I'm all for removing steps in getting involved, but it feels like if we had everything under openstackID and no CLA that would already go a long way
15:39:43 <mnaser> does openstackid also allow you to login via third party things like 'login with google' or 'login with github'
15:39:49 <clarkb> mnaser: no
15:39:52 <mnaser> ok
15:40:00 <clarkb> it is the third party thing you login with
15:40:04 <mnaser> oh i see
15:40:06 <dhellmann> what tools are we using today that are tied to using launchpadid?
15:40:06 <clarkb> so login to gerrit with openstackid
15:40:15 <mnaser> so it is like "login with google"
15:40:17 <fungi> i also think that with the new pilot projects under the osf we have an opportunity to maybe push on even the sso/ccla concerns. for example, kata uses the dco and github. there's no tie-in for ccla tracking (nor even a ccla at all, i'd warrant)
15:40:19 <ttx> dhellmann: launchpad, gerrit
15:40:31 <dhellmann> could we change gerrit to use the openstackid service?
15:40:33 <clarkb> mnaser: but it will be more transparent if we continue to sso it
15:40:39 <dhellmann> and storyboard?
15:40:51 <clarkb> mnaser: I guess thats the difference I'm failing to articulate
15:40:53 <dhellmann> we're close to in a state where using launchpad is optional, aren't we?
15:40:56 <fungi> and the wiki
15:41:00 <dhellmann> and the wiki
15:41:12 <clarkb> storyboard
15:41:14 <zaneb> could we change gerrit to use *any* openID provider?
15:41:23 <fungi> zaneb: we _could_ yes
15:41:31 * ttx needs to run
15:41:35 <dhellmann> fungi , clarkb : right, what is holding us back from changing off of launchpad today?
15:41:37 <fungi> right now the reason we can't is entirely a legal one
15:41:44 <clarkb> dhellmann: cla
15:42:00 <dhellmann> clarkb : I don't understand that answer, can you give me more details?
15:42:10 <mnaser> fungi: sorry, can you please explain the legal reason we cant? (i'm sorry if this was discussed often in the past)
15:42:17 <clarkb> there are other concerns I hvae with making a switch to any openid provider as well. The biggest one having 10 accounts because you have 10 openids and never remember which you used last
15:42:33 <dhellmann> I don't want to switch to any provider, I want to switch to the one the foundation runs
15:42:49 <dhellmann> what prevents us from switching from launchpad to openstackid as the provider?
15:43:32 <fungi> mnaser: if we want to drop the icla yet in favor of the dco, the board (on behalf of legal counsel from a number of member companies many of whom i thnik aren't involved any longer) decided that we needed to provide an alternate means of tracking contributors which would allow them to match them up against contributor lists on their respective cclas
15:44:06 <zaneb> clarkb: can't they all tie back to one email?
15:44:21 <fungi> and the solution they agreed to was moving them to an authentication system controlled by the osf so that it would integrate directly with ccla tracking mechanisms the osf web dev team have put together
15:44:45 <zaneb> ah, ok
15:44:58 <clarkb> dhellmann: for a direct move I don't think there are legal concerns it just requires that we figure out how to migrate everyone and do the database updates and delete the auth cache
15:45:31 <clarkb> zaneb: I've not seen an consumer of openid implement it that way. Typically an openid (which is a url) maps to an account and then the other data like name and email is largely arbitrary
15:45:33 <mnaser> fungi: thank you for that summary, all makes sense now
15:45:39 <fungi> right, there's a fair amount of overlap, but wedon't have a perfect 1:1 mapping of login.ubuntu.com to openstackid.org accounts
15:45:41 <dhellmann> clarkb : ok. that feels like something we could go ahead and do, then? (modulo having someone to do the work, of course)
15:45:49 <clarkb> zaneb: so if you login with a new openid that is a new account
15:45:59 <fungi> partly because launchpad makes keeping your e-mail address private a default behavior
15:47:26 <fungi> we can build up a mapping by comparing openids on the systems we have to e-mail addresses tracked by some of those systems and then try to get a more exact match (though it still won't be 100% because not everyone using our lp-authenticated systems has signed up for an openstack.org account)
15:48:14 <fungi> so whatever solution we settle on will need to involve ways for people to link up their "old" accounts with new ids manually
15:48:34 <dhellmann> could we do that by having folks login to a special page on openstack.org using the launchpad provider?
15:49:17 <fungi> yes, that's one of the solutions we've talked about, though that just gets us the mapping. we still need to have some way of updating the ids in the respective systems once that's done
15:49:30 <dhellmann> like, login to your openstack account and go to the profile page and click the "link my launchpad id" button?
15:49:31 <dhellmann> sure
15:50:08 <fungi> for people we can map in advance we can make it fairly seamless. for the rest, we'd either need some dangerous automated process performing database updates on gerrit, mediawiki, storyboard, et cetera or we need to manually batch those
15:50:50 <cdent> Just to reset this conversation a bit, I think we all need to check our privilege a bit: When we have evidence from people not in power (ie not us) that they are experiencing barriers the correct response is "I didn't realize that, we'd like to do better". I don't feel like we're doing that.
15:50:55 <dhellmann> I wonder where the cut-off is for people who actually need to have the mapping done vs. just creating a new account
15:51:07 <mnaser> not that i want to complicate things more but not sure how that all falls into the 'winterscale' initiative
15:51:35 <mnaser> is openstackid still going to be a thing.. is it going to be winterscaleid if we're hosting other things, i dont know the answers but something to keep in mind
15:51:49 <dhellmann> cdent : what should we be talking about then?
15:51:59 <clarkb> cdent: I think we've also largely dealt in hypotheticals, a specific "this is what I find difficult" may be helpful if we want to talk about not realizing problems and going from there to make things better
15:52:21 <clarkb> and I don't just mean "gerrit" what specifically about gerrit is difficult
15:52:28 <cdent> We should be more strongly recognizing the proble and analysing it before going straight to detailed technical solutions. There's little evidence that we've ack'd the problem
15:52:42 <cdent> clarkb: right, more analysis required
15:52:52 <dhellmann> cdent : one problem presented was having to sign up for multiple accounts. Removing launchpad means removing 1 account.
15:53:41 <cdent> dhellmann: sure, but I think going to details on that is premature
15:53:42 <dhellmann> we have to have the openstack account to track affiliations and CLA anyway, so that one can't go away
15:53:46 <cdent> it could easily be wasted energy
15:53:55 <cdent> there may be other things which are more relevant
15:54:32 <dhellmann> the question I posed was "what stops us from moving from launchpad to openstackid" for authenticating to the things we want to be our default services. the answer was technical because there is not a legal concern (which is what I was really worried about). I don't see a problem with that.
15:55:16 <cdent> do we know that moving from launchpad to openstackid will have any impact on so-called casual contribution? Or do we just think so?
15:55:18 <dhellmann> "could" and "may" -- do you think there are?
15:56:01 <dhellmann> I don't *know* anything. I'm trying to explore options.
15:56:17 <mnaser> i might argue it makes things worse because now you go from POSSIBLY having a launchpad account already to now having to create "this openstack account"
15:56:40 <cdent> Well, from the people I've spoken with, needing to get on the island in the first place is the main barrier, but conversation here seems to indicate that is an insurmountable change. If that's the case, I don't think logins makes much difference.
15:56:58 <dhellmann> fungi : can you remind me what prevents us from allowing individuals to use the DCO instead of CLA?
15:57:18 <dhellmann> cdent : I don't know what your island metaphor means.
15:57:26 <clarkb> cdent: the specific concern you've heard then is simply that we aren't github?
15:57:44 <clarkb> dhellmann: I think it basically means we don't use the tools they are already using
15:57:49 <clarkb> dhellmann: whcih for many is github
15:58:29 <cdent> clarkb, dhellmann : it's certainly one of the issues people report. And, like I said above, I'm not saying "unless we switch to github we are screwed". I'm saying there are factors out there we look at.
15:59:02 <dhellmann> ok, well, we also talked about the technical, social, and legal barriers to having github prs imported into gerrit
15:59:10 <cdent> But perhaps fungi has a point: maybe, because we don't have enough cores, we don't actually want more contributions?
15:59:17 <fungi> dhellmann: providing a means for interested legal representatives of various openstack member companies to map contributions to employees who are or aren't tracked in their respective cclas
15:59:26 <dhellmann> so I feel like we're actually talking about many things, not solely focusing on any 1 thing
15:59:50 <fungi> dhellmann: basically the board said we could drop the icla and do this dco thing _if_ we made it easier for them to cover everyone under cclas
15:59:57 <jroll> this seems like one of those topics where we are unable to agree on the problems without immediately diving into the technical details of solutions and why they won't work :(
16:00:20 <fungi> a big part of it is that they don't believe we actually have "individual contributors" (or at least that those people aren't enough of a legal threat to care about)
16:00:45 <dhellmann> jroll : there's a lot of history to some of these topics, and we can't ignore it
16:00:45 <mnaser> i think the issue here that i brought up was that we operate our infrastructure in a silo
16:00:58 <dhellmann> what I'm hearing is that
16:01:01 <mnaser> and i dont know if dco/icla/legal stuff is the reason behind it
16:01:04 <dhellmann> 1. people don't want to use tools other than github
16:01:23 <dhellmann> 2. we have some legal issues with contributions from random anyones
16:01:31 <fungi> mnaser: agreed, i'd like to widen our silo and help people who are interested in software freedom work on projects which eschew non-free tools
16:01:38 <dhellmann> 3. we have considered many technical solutions to ease the transition
16:01:59 <fungi> i personally care 0 about people who like to use proprietary tools. they can go make proprietary communities and software for all i care
16:02:00 <dhellmann> 4. work on that has stalled (perhaps there's a better word) but is not blocked because of any legal decisions
16:02:05 <dhellmann> is that right?
16:02:36 <cdent> it appears there's a 5: some people on the tc care 0
16:03:05 <cdent> I agree that's a fine position to hold as an individual, but not one that is particular responsible here
16:03:06 <fungi> i care a lot about making free tools easier to use
16:03:11 <dhellmann> I think it's more constructive for us to focus on friction in the tools we're using than to continue to rehash an argument about free or non-free tools
16:04:14 <mnaser> dhellmann: agreed.  at the end of the day, i think it's about growing the community as a whole
16:04:37 <jroll> dhellmann: is that history documented somewhere? it seems like every time we discuss these things there's a giant wall of text and 3+ concurrent conversations, which makes it impossible for people without the history in their head to understand it
16:04:50 <dhellmann> jroll : no, that's why I keep asking these questions today :-/
16:05:01 <jroll> right
16:05:06 <dhellmann> it would be good to get it written down somewhere
16:05:14 <dhellmann> maybe someone wants to volunteer to summarize today's discussion?
16:05:16 <jroll> so when I say we haven't agreed on the problems
16:05:26 <jroll> I don't think we have a full list of barriers for casual contributors
16:05:42 <jroll> and we *definitely* don't have a list of things like "we can't fix barrier X because legal"
16:05:58 <jroll> which is a problem that should be considered when we talk about fixing the "barrier" problem
16:06:12 <clarkb> re silo of tools, basically the entire LF but cncf use Gerrit too. As does golang, android and its ecosystem, chromium (basically the big google open source projects). Eclipse, mediawiki, libreoffice, and others all gerrit as well. I don't think its fair to paint a picture we are the only gerrit weirdos out there
16:06:37 <cmurphy> ++
16:06:52 <mnaser> i knew about LF but i didnt know about all those other users like eclipse and mediawiki etc
16:07:10 <cmurphy> we've been cultivating this workflow for years because we know it works really quite well for collaboration across huge communities, it is not an arbitrary NIH decision
16:07:24 * dhellmann notes the lack of volunteers to summarize this discussion
16:07:50 <mnaser> :(
16:07:52 <jroll> I'm having trouble summarizing it for myself, let alone a general audience
16:07:53 <zaneb> cmurphy ++
16:07:56 <fungi> also worth noting, many (though not all) of those communities use gerrit now because we showed them it was a better alternative
16:08:00 <fungi> and led by example
16:08:14 <zaneb> github is terrible because pull requests are the wrong model
16:08:32 <fungi> dhellmann: if i knew what needed summarizing i'd volunteer gladly
16:08:37 <mnaser> oh i think github workflow is terrible :p
16:08:54 <mnaser> but i'm trying to see it in the view of potentially those who like it
16:09:06 <mnaser> which, given the valuation they recently were bought out as, there's a few people who use it...
16:09:08 <jroll> I believe github is perceived as awesome for people that haven't used better code review tools (many people). I also believe it takes weeks or months of using gerrit to understand why it is better.
16:09:17 <mnaser> jroll: agreed
16:09:28 <cmurphy> as a side note, a lot of people on my team internally has familiarity primarily with gerrit and very little experience with github and find github very unapproachable
16:09:50 <dhellmann> fungi : we've talked about known issues with onboarding; blockers for streamlining logins; the requirements we have around CLA and DCO
16:09:52 <cdent> Just to be clear: I'm not suggesting we bail and stop using gerrit or switch over to github. Rather that people who express that not using it is a problem have useful input.
16:09:58 <fungi> i don't personally know people who "like" github, except in comparison to other even worse tools they've used in the past. most people i know who use it do so because they're not aware of alternatives
16:10:17 <jroll> also of note: a huge amount of people new to software development are encouraged to contribute to OSS for their resume. a huge number of OSS projects (especially ones small enough for noobies to understand) are on github. so a large number of college grads come out knowing github and nothing else
16:10:31 <clarkb> fungi: I think a history of how we ended up on gerrit (from bzr/lp), and how the CLA affects tooling choices due to legal concerns. Then summary of what we've said here about how it relates to today is what dhellmann and jroll are looking for
16:10:32 <jroll> I know tons of people who like github
16:10:55 <dhellmann> clarkb : yeah, that would be good
16:11:05 <jroll> clarkb: ++
16:11:26 <fungi> clarkb: dhellmann: oof, while i can wax nearly endlessly on those topics, coming up with appropriate citations from the annals of openstack history will take a lot of time. but i'm willing to prioritize it if that will keep this conversation from repeatedly coming up
16:11:50 <clarkb> fungi: maybe don't cite it and just say "this is fungis historical perspective" )
16:11:57 <dhellmann> fungi : even without citations it would be useful. we can work on the citations seprately
16:12:01 <fungi> jroll: heh, sounds like the historical reasons for the rise and fall of java
16:12:02 <clarkb> then we can work backward from that if necessary
16:12:04 <jroll> yep, I'm fine without citations
16:12:07 <zaneb> cdent: so... yes... but it's not actionable. the tradeoff is between a bad tool that lots of people have already learned how to use and possibly have an account on, and a less bad tool that only some (very large) isolated communities use
16:12:23 <zaneb> cdent: that tradeoff isn't going away. there's no way to split the difference
16:12:31 <jroll> fungi: heh
16:12:36 <clarkb> worth noting that gitub is why we gerrit today iirc :)
16:12:39 <cdent> zaneb: it is actionable. we find some of those people, and talk to them and find out some things we can tune, doing that doing without making assumptions about the problems
16:12:51 <cdent> s/that doing/that tuning/
16:12:56 <clarkb> we went to them asking for a couple features to make github work with openstack and they told as to go away
16:13:33 <jroll> clarkb: just making a guess at the problems, but funny enough I believe they are solved now
16:13:36 <clarkb> fungi: ^ you can put that in your history uncited :P monty can probably give better background on that though
16:13:41 <cdent> zaneb: that's all I'm really pushing for here: the usual: let's speculate less and engage with peopple.
16:13:46 <jroll> mandatory reviews, protected branches, CLA things, etc
16:13:47 <cmurphy> a ton of people have asked them for features that go unsolved https://github.com/isaacs/github/issues
16:13:52 <fungi> yeah, there was that brief "we need to move off bzr" period where we didn't know what git service we should collaborate in
16:14:32 <fungi> cmurphy: in fairness, the feature request wishlist for gerrit is miles long too and as we learned running a fork of it gets painful real fast
16:14:58 * dhellmann looks at the feature backlog of openstack
16:15:07 <cmurphy> fungi: but at least it's open source and someone could theoretically submit a patch
16:15:13 <cmurphy> no go with github
16:15:16 <fungi> dhellmann: best you just don't even open the lid on that one ;)
16:15:22 <dims> LOL
16:15:24 <cdent> gitlab :)
16:15:39 <clarkb> jroll: ya in the last 9-12 months they've improved a lot of it but it took them what, 7 years?
16:15:59 <jroll> clarkb: yeah, just thought it was interesting that they eventually did what we needed
16:16:01 <fungi> having used gitlab i find it not entirely terrible, but it's copied a lot of pain from github for the sake of feature parity. also it's more open-core than gerrit (but gerrit is almost open-core too)
16:16:08 <dhellmann> I am not interested in optimizing our developer experience for individuals who write 1 patch a year. I *am* interested in *improving* their experience.
16:16:34 <cdent> dhellmann: that's a good way to put it
16:17:00 <zaneb> ++
16:17:10 <fungi> i'm starting to think that our thursday office hour is just going to be a double-hour most weeks
16:17:21 <cdent> seems like it
16:17:22 <jroll> cmurphy | as a side note, a lot of people on my team internally has familiarity primarily with gerrit and very little experience with github and find github very unapproachable <- missed this until now, but have seen the same. people are going to like what they're familiar with, for any type of tool
16:17:23 <dhellmann> we do call it "office hours" right? :-)
16:17:24 <mnaser> fungi: making up for all the other ones :)
16:17:40 * jroll would love to see those two hours spread across the week more
16:17:46 <fungi> mnaser: yeah, wednesday was a total bust this week
16:18:07 <mnaser> i personally struggle with github, but then it's probably cause i don't use it often enough
16:18:13 <mnaser> i guess people feel the same about gerrit..
16:18:25 <fungi> jroll: if only we could figure out how to make cdent and ttx not need sleep
16:18:28 <jroll> "cram it all into an hour or two" makes things super unapproachable, I had a meeting overlap which made it hard to comment on some things I wanted to comment on
16:18:39 <clarkb> mnaser: that is some of it but some things are just objectively bad. Highest on my list is not preserving review history
16:18:57 <clarkb> mnaser: they recnetly improved this by keeping diffs and comments around but that is it, you can't fetch real commits
16:18:57 <jroll> fungi: there are options but their coherency might taper off :P
16:19:02 <dhellmann> jroll : I've given that some thought, and I wonder how much the "clumping" of conversation has to do with the fact that people are usually busy doing many things, so having a dedicated time makes it easy to leave topics until we know others are going to be around.
16:19:15 <mnaser> i think for github users trying/using gerrit is the idea of a 'single commit'
16:19:21 <fungi> also my coherency tapers off before the 01:00 utc office hour starts most weeks
16:19:42 <mnaser> and amending onto your commit and pushing that up, probably not a concept they are used to
16:19:49 <mnaser> (for revisions)
16:19:57 <jroll> dhellmann: yeah, I suspect that's part of it. I wonder if folks would still dedicate time to have discussions here if we didn't have scheduled time, or if we would just talk less
16:20:02 <fungi> mnaser: in contrast, it's pretty easy for people coming from the lkml to wrap their heads around
16:20:07 <dhellmann> clarkb : having some of that detail in fungi's write up about why we prefer gerrit would be good
16:20:20 <fungi> yeah, i plan on rereading this entire log
16:20:23 <dhellmann> jroll : I'm worried we would talk even less :-/
16:20:30 <mnaser> fungi: oh of course :)
16:20:31 <jroll> me too
16:20:31 <fungi> before i even start to attempt to summarize
16:21:56 <fungi> mnaser: i have a feeling it's not coincidental that the largest free software project (before openstack at least according to some people) use a very similar patch review workflow as we do, even if we use a different toolset and approval structure
16:23:09 <dims> folks, fyi, i'll be out next week (vacation)
16:23:16 <mnaser> fungi: i think we happen to have one of the best tooling and i enjoy using it.
16:23:19 <fungi> dims: thanks for the heads up
16:23:45 <smcginnis> GitHub does not really scale well to large communities, at least in my opinion. Without a lot of custom tooling to handle it.
16:23:57 <mnaser> i think we all agree gerrit is great, but i guess i'm just trying to think about the people who aren't in this conversation..
16:24:04 <cdent> mnaser++
16:24:07 <mnaser> maybe they might think gerrit is great too, none of us can answer this except them :)
16:24:07 <fungi> c.f., the kubernetes and ansible communities struggling with it now
16:24:09 <zaneb> fungi: right, GitHub copied the wrong part of the kernel workflow, and have been unwilling or unable to acknowledge that ever since
16:24:36 <zaneb> pull requests are great for a branch *in which all of the patches have already been reviewed*
16:24:46 <zaneb> they're terrible for code review
16:24:48 <fungi> yup
16:25:15 * mnaser has to run and setup for a 12:30 call, dropping off.
16:25:25 <dhellmann> mnaser : so let's start by writing down why we think it's good, and then we can get people to tell us where their opinions differ
16:25:42 * jroll just makes single-commit pull requests in a chain when using github
16:25:59 <mnaser> fwiw github added a 'squash changes and merge' feature or something
16:26:16 <mnaser> dhellmann: i think that's good, i dont know if i currently have time to write that up though, sorry
16:26:18 <jroll> should probably make a little github PR chain management tool
16:26:19 * mnaser actually has to go now :p
16:26:26 <fungi> thanks mnaser!
16:26:40 <dhellmann> jroll : I think jd__ has done some work on that, you should check with him
16:26:50 <jroll> neat, thanks :)
16:26:57 <clarkb> dhellmann: they've made it a paid srvice even
16:26:59 <fungi> yeah, gnocchi needed something to make working with github tolerable
16:27:10 <fungi> after they were used to developing in gerrit
16:27:15 <cdent> yeah, jd_ has done quite a bit of github tooling, including starting a company about it
16:27:18 <clarkb> https://mergify.io/
16:27:21 <cdent> jinx
16:29:05 <fungi> looks sort of like a zuul scheduler
16:29:38 <fungi> but without the ci and speculative execution
16:29:50 <clarkb> fungi: its more like the prolog in gerrit I Think
16:29:56 <fungi> true
16:30:27 <clarkb> prolog as a service
16:32:17 <dtroyer> Anyone know if the day for the PTG-located board meeting been set yet?
16:32:31 <smcginnis> dtroyer: I was wondering the same thing. Haven't seen anything yet.
16:33:20 <fungi> it sounded like that might not be happening after all
16:33:25 <fungi> i'll double-check
16:34:35 <fungi> yeah, erin just confirmed it for me
16:34:49 <fungi> smcginnis: dtroyer: ^ no board of directors meeting at the ptg this time
16:35:12 * cdent sighs
16:35:26 <smcginnis> fungi: Oh... is there going to be a different opportunity for real time communication between the groups?
16:35:59 <fungi> probably berlin? i want to say we'd talked about scaling it back to two joint leadership meetings a year?
16:36:13 <smcginnis> :/
16:36:28 <dtroyer> heh, ok, thanks fungi.  that'll be interesting for the things being deferred until that specific meeting… :)
16:36:46 <fungi> the argument for two was that we seem to mostly spend the time just rehashing the same things, if memory serves
16:37:08 <cdent> dtroyer++
16:37:13 <mugsie> I do not think that woulkd have been a problem this time
16:37:21 <smcginnis> And that couldn't possibly be because folks need to be reminded what those things were.
16:37:22 <fungi> i want to say that came up at the joint meeting at the last ptg
16:37:31 <mugsie> and it was only some people pushing for two
16:37:56 <persia> As an observer, I generally see progress on about half the things brought up at each joint meetings, with deferment to the next for the other half.  Given my general experience with repeating governance meetings, I think that is fairly normal, regardless of cadence.
16:38:10 <fungi> persia: i tend to agree
16:39:13 <mugsie> it does highlight the board <> TC communication issues quite succinctly though
16:39:13 <fungi> actually, i guess there wasn't one. must have been sydney?
16:39:24 <dtroyer> the things I am thinking about are not things deferred from a prior meeting, but "until the next f2f" that also happen to fall within a 1-year window that expires approx at the next f2f in Berlin
16:39:30 <fungi> we're already on the semi-annual cadence looks like
16:39:42 * mugsie goes back to driving a fire truck
16:39:51 <fungi> we met in sydney in november, then vancouver in may, and will probably meet again in berlin in november
16:40:41 <fungi> right, the board met in person in dublin but there was no joint leadership meeting because it overlapped with the first day of the ptg
16:40:43 * cdent gives mugsie a nice hat
16:41:26 <persia> Several members of the TC attended various topics at the board meeting at the PTG in Dublin, some of which seemed very openstack-the-project specific (vs. general foundation).  I am surprised that it was not formally a joint meeting.
16:41:29 <smcginnis> At least in Dublin there was an opportunity to sit in if you could juggle your schedule.
16:42:14 <mugsie> persia: some members of the board pushed for a meeting during the PTG, which hosed that plan
16:47:16 <cdent> I think we're going to need to be pretty concerted and attentive in our efforts to insure that communications between tc, uc, board and other "top-level projects" is good.
16:47:23 * cdent states the obvious
16:47:47 <smcginnis> ++
16:47:57 <smcginnis> Should we end the "meeting"?
16:48:07 <cdent> yeah, we've tailed off
16:48:09 <cdent> #endmeeting