15:00:21 #startmeeting tc 15:00:24 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 tc-members let's assemble 15:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:27 The meeting name has been set to 'tc' 15:00:29 #topic Office Hour 15:00:37 #chair ttx cdent 15:00:38 Current chairs: cdent fungi ttx 15:00:39 o/ 15:00:44 #chair smcginnis 15:00:44 Current chairs: cdent fungi smcginnis ttx 15:01:16 o/ 15:01:29 #chair mnaser 15:01:30 Current chairs: cdent fungi mnaser smcginnis ttx 15:01:47 o/ 15:01:59 #chair dhellmann 15:02:04 Current chairs: cdent dhellmann fungi mnaser smcginnis ttx 15:02:07 Maybe we need a standard single #chair line we can paste for the whole TC. :D 15:02:14 this is more fun somehow 15:02:23 because of all the pinging 15:02:30 ;) 15:02:34 heh 15:02:40 o/ 15:02:40 we could make it a chain. each person who is chaired has to chair the next in line 15:02:48 it's like saying hello :-) 15:02:49 zaneb: you around? Is adjutant a topic we need to hash today? 15:02:51 go for it 15:02:58 oh, that's me 15:03:03 #chair cmurphy 15:03:04 Current chairs: cdent cmurphy dhellmann fungi mnaser smcginnis ttx 15:03:18 we're up to 7 out of 13, not bad 15:04:02 how are folks doing with their liaison outreach? has anyone had trouble reaching a team's PTL? 15:04:16 I have not gotten there yet. :/ 15:04:29 * cmurphy hasn't started yet 15:04:29 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 Should be able to do that today. Or at least get started on it. 15:04:31 anybody who wants to weigh in on the castellan base service addition thread revival from yesterday, please do 15:04:41 feeling like i might be biased in my opinion in a way 15:05:03 mnaser: On the other hand, you have a really good feel for the state of the project. 15:05:03 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 Did two, went well and was appreciated i think 15:05:12 mnaser : that's a good insight, and it's part of why I wanted 2 people on each project. 15:05:25 dhellmann: any opinion on my traffic lights icons ? 15:05:41 Are there more questions about Octavia's support of both Barbican and Castellan? 15:05:45 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 I was thinking just in summaries, as a business summary 15:06:29 wfm 15:06:34 I don't want it to turn into yet another badge 15:06:41 yeah, good point 15:06:53 and I feel like a table at the top would... facilitate that 15:06:55 o/ 15:07:00 #chair dims 15:07:00 Current chairs: cdent cmurphy dhellmann dims fungi mnaser smcginnis ttx 15:07:23 yeah i feel health being a tag would be problematic for the growth of the project and general morale 15:07:37 dhellmann: I was wondering what would be the color of Requirements after your check 15:07:39 Agree 15:07:59 needing urgent action (red) or just a warning (orange) ? 15:08:04 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 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 stain* 15:08:31 ttx: very dark orange? :-) 15:08:39 Burnt umber 15:08:44 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 Basically if the team requires further work from eth TC, I'd put red 15:08:57 (recalling nova team discussion) 15:09:05 like if you create a storyboard entry about it, then red 15:09:23 orange is like... we need to pay some attention 15:09:26 *only* if the team asks for it too imho (im assuming thats what you mean) 15:09:27 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 ttx: that seems like a good way to draw the distinction 15:09:55 mnaser: yeah, we had a discussion about it with cdent... Hard to balance 15:09:59 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 fungi: I'm happy retiring them once they start being a bit too... public 15:10:31 It's just a convenient shortcut 15:11:19 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 the OSA team overall is going through a really hard time right now 15:12:26 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 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 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 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 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 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 yes, I suspect that's going to be something we see for several teaems 15:16:37 the requirements team is in the same state 15:17:05 it seems to me that the projects that help the underlying infrastructure to support the ecosystem struggle usually 15:17:07 murano, to some degree as well 15:17:08 requirements, deployment projects 15:17:31 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 fungi: right, but ansible is (in my opinion) the 'hotness' and it's struggling 15:18:25 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 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 mnaser: i agree, ansible lacking a groundswell of support in openstack seems anomalous 15:18:53 i totally agree, we have to let go of somethings at some point 15:19:30 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 which is super super cool and hopefully brings more contributions 15:19:43 mnaser: I've seen that as well. 15:20:05 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 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 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 tag with low-hanging-fruit 15:21:24 right, but in the bigger picture, i really do wonder if our choice of tooling makes it harder for new contributors 15:21:43 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 It's definitely a worthwhile topic. Our workflow is a learning curve, and learning curves are not friendly to casual-ness 15:22:48 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 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 do you have some specific alternatives in mind? 15:23:55 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 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 part of the "problem" there is that code review is also not friendly to casual-ness, regardless of the tooling 15:24:35 mnaser : is the problem "git" or "gerrit"? 15:24:47 fungi : yeah, that's true 15:24:48 mnaser: the way you frame that makes it sound like our workflow was an arbitrary choice, and it's not 15:24:54 i think the problem is having standards and holding code submissions to those standards 15:25:03 i think gerrit. it's too specific and tied into our own little ecosystem 15:25:07 depending on how you want to define "problem" 15:25:15 maybe we should find a way to allow users to login via github and automatically import their keys to gerrit? 15:25:16 Please no github PRs. 15:25:26 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 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 dhellmann: Was just thinking that through. 15:26:12 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 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 The trick would be creating gerrit accounts automatically for the github users. 15:26:34 * jroll points out http://gerrithub.io/ 15:26:40 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 notably "Keep in touch with external users synchronizing pull requests with reviews." 15:26:42 gerrithub is terrible imo 15:26:49 I haven't used it, fwiw 15:26:50 they completely nuked jenkins a few years back 15:26:56 In bold are the ones that should have their diversity tags changed, if we don't change anything 15:26:59 and jenkins had to get github to restore from backup 15:27:06 lol ^ 15:27:07 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 [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 They are roughly ordered in levels of diversity, the idea being to track evolution rather than binary tags 15:27:33 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 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 dtroyer : having a group going through the process together certainly helped me, back in the day 15:28:20 fungi: yes, that is awful and super horrible ux unfortunately 15:28:31 i had to on-board someone and i was confused for a while why 'git review' would keep rejecting commits 15:28:37 until i ran it with -vvv and i got the icla warning 15:28:59 ttx: thanks for preparing that info 15:29:24 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 Hmm, stackalytics appears to be broken. 15:29:38 mnaser: aiui you get a message if using current git review 15:29:46 mnaser: it actually comes from gerrit 15:29:48 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 smcginnis: indeed, I wanted to refine the stats this morning to prepare for this and failed 15:29:55 (we can test that and confirm) 15:30:04 brew install git; brew install git-review .. just yesterday, it was flat out 'refusing it' 15:30:08 but could be different versions 15:30:09 * ttx need to jump off in 10 min 15:30:19 mnaser: what version does brew install? 15:30:24 fungi , mnaser : getting everyone onto storyboard would let us drop launchpad, which would mean 1 less account to configure 15:30:34 clarkb: git-review: stable 1.26.0 (bottled) 15:30:41 mnaser: pip install git-review may be more up to date. 15:30:55 mnaser: ok its possible gerrit update broke that passthrough of error messages 15:31:03 o/ 15:31:09 #chair zaneb 15:31:10 Current chairs: cdent cmurphy dhellmann dims fungi mnaser smcginnis ttx zaneb 15:31:20 clarkb: yeah maybe someone should look into that, it certainly confused me 15:31:35 ttx, smcginnis: maybe infra can try taking over hosting of stackalytics? 15:31:46 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 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 github and openstack are not in the same category of thing 15:32:17 ttx: are the comments like "50.25% top core review %" the reason for a team not having the diversity tag? 15:32:17 cdent: but from a difficulty perspective they ar ethe same 15:32:22 its not more difficult you just have to do it again 15:32:30 dhellmann: yes, or worst 'stat' 15:32:31 cdent: sure, one is a proprietary cesspool and the other is a software community built on free principles 15:32:31 there is value in not having to do it again 15:32:35 but it isn't more difficult imo 15:32:36 ttx: ok 15:32:54 dhellmann: trying to expose the subjectiveness of the exercise 15:32:59 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 dhellmann: given the limited quality of input data :) 15:33:17 fungi: while i 100% stand by the free principles idea, i just worry that it's *might* be affecting our growth 15:33:33 mnaser: depends what you call growth :) 15:33:38 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 fungi: you're special right, you realize that, yeah? 15:33:58 ttx: i guess attracting new contributors and making it easier for casual ones to push things up 15:34:08 I'm not defending github 15:34:19 But nor am I willing to defend how openstack does things. 15:34:22 also i think unbounded growth is a big part of the problem. in biology it would be akin to a cancer 15:34:45 we've dealt with the growth, now we need to avoid death 15:34:50 i'm much in favor of shrinking 15:35:14 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 mnaser++ 15:35:40 all of my non-openstack tech-friends tell me that all the time 15:35:53 i'm not sure why we're looking for an audience. that in itself sounds like failure 15:35:57 they feel like you have to join a club and learn the secret handshakes 15:36:20 fungi: because we keep saying we need and want casual contributors 15:36:28 if we don't, cool. 15:36:47 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 contributing to any decently-sized project is complicated, GitHub or not 15:36:58 looking for an audience isn't necessarily the same thing as improving our tools and workflows 15:37:14 You have things like CLAs 15:37:20 a process, rules 15:37:34 I'm not sure most of our pain comes from choice of tools 15:37:44 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 vs. the learning curve of shared understandings 15:37:59 or the CLA signing 15:38:00 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 IMO what we want is for *people who use OpenStack* to also contribute back 15:38:23 zaneb: i agere 15:38:28 that's what i feel it is 15:38:30 even if it is not their full-time job 15:38:36 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 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 zaneb: "casual contributors" to me is people deploying openstack in their organization who see a problem and want to fix it 15:38:55 so contributing a patch is not anywhere close to the top of their priority list 15:38:58 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 does openstackid also allow you to login via third party things like 'login with google' or 'login with github' 15:39:49 mnaser: no 15:39:52 ok 15:40:00 it is the third party thing you login with 15:40:04 oh i see 15:40:06 what tools are we using today that are tied to using launchpadid? 15:40:06 so login to gerrit with openstackid 15:40:15 so it is like "login with google" 15:40:17 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 dhellmann: launchpad, gerrit 15:40:31 could we change gerrit to use the openstackid service? 15:40:33 mnaser: but it will be more transparent if we continue to sso it 15:40:39 and storyboard? 15:40:51 mnaser: I guess thats the difference I'm failing to articulate 15:40:53 we're close to in a state where using launchpad is optional, aren't we? 15:40:56 and the wiki 15:41:00 and the wiki 15:41:12 storyboard 15:41:14 could we change gerrit to use *any* openID provider? 15:41:23 zaneb: we _could_ yes 15:41:31 * ttx needs to run 15:41:35 fungi , clarkb : right, what is holding us back from changing off of launchpad today? 15:41:37 right now the reason we can't is entirely a legal one 15:41:44 dhellmann: cla 15:42:00 clarkb : I don't understand that answer, can you give me more details? 15:42:10 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 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 I don't want to switch to any provider, I want to switch to the one the foundation runs 15:42:49 what prevents us from switching from launchpad to openstackid as the provider? 15:43:32 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 clarkb: can't they all tie back to one email? 15:44:21 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 ah, ok 15:44:58 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 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 fungi: thank you for that summary, all makes sense now 15:45:39 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 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 zaneb: so if you login with a new openid that is a new account 15:45:59 partly because launchpad makes keeping your e-mail address private a default behavior 15:47:26 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 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 could we do that by having folks login to a special page on openstack.org using the launchpad provider? 15:49:17 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 like, login to your openstack account and go to the profile page and click the "link my launchpad id" button? 15:49:31 sure 15:50:08 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 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 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 not that i want to complicate things more but not sure how that all falls into the 'winterscale' initiative 15:51:35 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 cdent : what should we be talking about then? 15:51:59 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 and I don't just mean "gerrit" what specifically about gerrit is difficult 15:52:28 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 clarkb: right, more analysis required 15:52:52 cdent : one problem presented was having to sign up for multiple accounts. Removing launchpad means removing 1 account. 15:53:41 dhellmann: sure, but I think going to details on that is premature 15:53:42 we have to have the openstack account to track affiliations and CLA anyway, so that one can't go away 15:53:46 it could easily be wasted energy 15:53:55 there may be other things which are more relevant 15:54:32 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 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 "could" and "may" -- do you think there are? 15:56:01 I don't *know* anything. I'm trying to explore options. 15:56:17 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 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 fungi : can you remind me what prevents us from allowing individuals to use the DCO instead of CLA? 15:57:18 cdent : I don't know what your island metaphor means. 15:57:26 cdent: the specific concern you've heard then is simply that we aren't github? 15:57:44 dhellmann: I think it basically means we don't use the tools they are already using 15:57:49 dhellmann: whcih for many is github 15:58:29 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 ok, well, we also talked about the technical, social, and legal barriers to having github prs imported into gerrit 15:59:10 But perhaps fungi has a point: maybe, because we don't have enough cores, we don't actually want more contributions? 15:59:17 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 so I feel like we're actually talking about many things, not solely focusing on any 1 thing 15:59:50 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 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 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 jroll : there's a lot of history to some of these topics, and we can't ignore it 16:00:45 i think the issue here that i brought up was that we operate our infrastructure in a silo 16:00:58 what I'm hearing is that 16:01:01 and i dont know if dco/icla/legal stuff is the reason behind it 16:01:04 1. people don't want to use tools other than github 16:01:23 2. we have some legal issues with contributions from random anyones 16:01:31 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 3. we have considered many technical solutions to ease the transition 16:01:59 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 4. work on that has stalled (perhaps there's a better word) but is not blocked because of any legal decisions 16:02:05 is that right? 16:02:36 it appears there's a 5: some people on the tc care 0 16:03:05 I agree that's a fine position to hold as an individual, but not one that is particular responsible here 16:03:06 i care a lot about making free tools easier to use 16:03:11 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 dhellmann: agreed. at the end of the day, i think it's about growing the community as a whole 16:04:37 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 jroll : no, that's why I keep asking these questions today :-/ 16:05:01 right 16:05:06 it would be good to get it written down somewhere 16:05:14 maybe someone wants to volunteer to summarize today's discussion? 16:05:16 so when I say we haven't agreed on the problems 16:05:26 I don't think we have a full list of barriers for casual contributors 16:05:42 and we *definitely* don't have a list of things like "we can't fix barrier X because legal" 16:05:58 which is a problem that should be considered when we talk about fixing the "barrier" problem 16:06:12 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 ++ 16:06:52 i knew about LF but i didnt know about all those other users like eclipse and mediawiki etc 16:07:10 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 :( 16:07:52 I'm having trouble summarizing it for myself, let alone a general audience 16:07:53 cmurphy ++ 16:07:56 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 and led by example 16:08:14 github is terrible because pull requests are the wrong model 16:08:32 dhellmann: if i knew what needed summarizing i'd volunteer gladly 16:08:37 oh i think github workflow is terrible :p 16:08:54 but i'm trying to see it in the view of potentially those who like it 16:09:06 which, given the valuation they recently were bought out as, there's a few people who use it... 16:09:08 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 jroll: agreed 16:09:28 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 fungi : we've talked about known issues with onboarding; blockers for streamlining logins; the requirements we have around CLA and DCO 16:09:52 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 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 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 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 I know tons of people who like github 16:10:55 clarkb : yeah, that would be good 16:11:05 clarkb: ++ 16:11:26 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 fungi: maybe don't cite it and just say "this is fungis historical perspective" ) 16:11:57 fungi : even without citations it would be useful. we can work on the citations seprately 16:12:01 jroll: heh, sounds like the historical reasons for the rise and fall of java 16:12:02 then we can work backward from that if necessary 16:12:04 yep, I'm fine without citations 16:12:07 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 cdent: that tradeoff isn't going away. there's no way to split the difference 16:12:31 fungi: heh 16:12:36 worth noting that gitub is why we gerrit today iirc :) 16:12:39 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 s/that doing/that tuning/ 16:12:56 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 clarkb: just making a guess at the problems, but funny enough I believe they are solved now 16:13:36 fungi: ^ you can put that in your history uncited :P monty can probably give better background on that though 16:13:41 zaneb: that's all I'm really pushing for here: the usual: let's speculate less and engage with peopple. 16:13:46 mandatory reviews, protected branches, CLA things, etc 16:13:47 a ton of people have asked them for features that go unsolved https://github.com/isaacs/github/issues 16:13:52 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 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 fungi: but at least it's open source and someone could theoretically submit a patch 16:15:13 no go with github 16:15:16 dhellmann: best you just don't even open the lid on that one ;) 16:15:22 LOL 16:15:24 gitlab :) 16:15:39 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 clarkb: yeah, just thought it was interesting that they eventually did what we needed 16:16:01 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 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 dhellmann: that's a good way to put it 16:17:00 ++ 16:17:10 i'm starting to think that our thursday office hour is just going to be a double-hour most weeks 16:17:21 seems like it 16:17:22 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 we do call it "office hours" right? :-) 16:17:24 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 mnaser: yeah, wednesday was a total bust this week 16:18:07 i personally struggle with github, but then it's probably cause i don't use it often enough 16:18:13 i guess people feel the same about gerrit.. 16:18:25 jroll: if only we could figure out how to make cdent and ttx not need sleep 16:18:28 "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 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 mnaser: they recnetly improved this by keeping diffs and comments around but that is it, you can't fetch real commits 16:18:57 fungi: there are options but their coherency might taper off :P 16:19:02 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 i think for github users trying/using gerrit is the idea of a 'single commit' 16:19:21 also my coherency tapers off before the 01:00 utc office hour starts most weeks 16:19:42 and amending onto your commit and pushing that up, probably not a concept they are used to 16:19:49 (for revisions) 16:19:57 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 mnaser: in contrast, it's pretty easy for people coming from the lkml to wrap their heads around 16:20:07 clarkb : having some of that detail in fungi's write up about why we prefer gerrit would be good 16:20:20 yeah, i plan on rereading this entire log 16:20:23 jroll : I'm worried we would talk even less :-/ 16:20:30 fungi: oh of course :) 16:20:31 me too 16:20:31 before i even start to attempt to summarize 16:21:56 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 folks, fyi, i'll be out next week (vacation) 16:23:16 fungi: i think we happen to have one of the best tooling and i enjoy using it. 16:23:19 dims: thanks for the heads up 16:23:45 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 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 mnaser++ 16:24:07 maybe they might think gerrit is great too, none of us can answer this except them :) 16:24:07 c.f., the kubernetes and ansible communities struggling with it now 16:24:09 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 pull requests are great for a branch *in which all of the patches have already been reviewed* 16:24:46 they're terrible for code review 16:24:48 yup 16:25:15 * mnaser has to run and setup for a 12:30 call, dropping off. 16:25:25 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 fwiw github added a 'squash changes and merge' feature or something 16:26:16 dhellmann: i think that's good, i dont know if i currently have time to write that up though, sorry 16:26:18 should probably make a little github PR chain management tool 16:26:19 * mnaser actually has to go now :p 16:26:26 thanks mnaser! 16:26:40 jroll : I think jd__ has done some work on that, you should check with him 16:26:50 neat, thanks :) 16:26:57 dhellmann: they've made it a paid srvice even 16:26:59 yeah, gnocchi needed something to make working with github tolerable 16:27:10 after they were used to developing in gerrit 16:27:15 yeah, jd_ has done quite a bit of github tooling, including starting a company about it 16:27:18 https://mergify.io/ 16:27:21 jinx 16:29:05 looks sort of like a zuul scheduler 16:29:38 but without the ci and speculative execution 16:29:50 fungi: its more like the prolog in gerrit I Think 16:29:56 true 16:30:27 prolog as a service 16:32:17 Anyone know if the day for the PTG-located board meeting been set yet? 16:32:31 dtroyer: I was wondering the same thing. Haven't seen anything yet. 16:33:20 it sounded like that might not be happening after all 16:33:25 i'll double-check 16:34:35 yeah, erin just confirmed it for me 16:34:49 smcginnis: dtroyer: ^ no board of directors meeting at the ptg this time 16:35:12 * cdent sighs 16:35:26 fungi: Oh... is there going to be a different opportunity for real time communication between the groups? 16:35:59 probably berlin? i want to say we'd talked about scaling it back to two joint leadership meetings a year? 16:36:13 :/ 16:36:28 heh, ok, thanks fungi. that'll be interesting for the things being deferred until that specific meeting… :) 16:36:46 the argument for two was that we seem to mostly spend the time just rehashing the same things, if memory serves 16:37:08 dtroyer++ 16:37:13 I do not think that woulkd have been a problem this time 16:37:21 And that couldn't possibly be because folks need to be reminded what those things were. 16:37:22 i want to say that came up at the joint meeting at the last ptg 16:37:31 and it was only some people pushing for two 16:37:56 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 persia: i tend to agree 16:39:13 it does highlight the board <> TC communication issues quite succinctly though 16:39:13 actually, i guess there wasn't one. must have been sydney? 16:39:24 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 we're already on the semi-annual cadence looks like 16:39:42 * mugsie goes back to driving a fire truck 16:39:51 we met in sydney in november, then vancouver in may, and will probably meet again in berlin in november 16:40:41 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 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 At least in Dublin there was an opportunity to sit in if you could juggle your schedule. 16:42:14 persia: some members of the board pushed for a meeting during the PTG, which hosed that plan 16:47:16 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 ++ 16:47:57 Should we end the "meeting"? 16:48:07 yeah, we've tailed off 16:48:09 #endmeeting