14:01:49 #startmeeting hubs-devel 14:01:49 Meeting started Tue Sep 19 14:01:49 2017 UTC. The chair is sayan. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:49 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:01:49 The meeting name has been set to 'hubs-devel' 14:01:50 it's here ! 14:02:27 #topic roll call 14:02:32 .hello sayanchowdhury 14:02:34 sayan: sayanchowdhury 'Sayan Chowdhury' 14:02:43 .hello pfrields 14:02:44 stickster: pfrields 'Paul W. Frields' 14:02:47 .hello duffy 14:02:47 .hello abompard 14:02:47 mizmo: duffy 'Máirín Duffy' 14:02:50 abompard: abompard 'Aurelien Bompard' 14:02:56 #chair stickster abompard mizmo 14:02:56 Current chairs: abompard mizmo sayan stickster 14:03:49 #topic Action items from the last meeting 14:03:55 sayan to create the PR for the IRC work 14:03:57 sayan to create a issue to track all the libraries (Python + JS) to be packaged 14:03:59 mizmo to create easyfix bounties for hubs 14:04:01 abompard and sayan to discuss the widgets for the outreachy proposal, and draft the outline of the proposal 14:04:03 sayan to create a etherpad page with the list of dates, and add it to the readme 14:04:30 yeh we are going to wait on the easyfix bounties until we have the outreachy applications complete 14:04:46 * mizmo is holding on that, unless we decide otherwise! 14:05:04 Yeah, we decided that during last meeting itself 14:05:34 +1 14:05:45 I did not get time to create the PR for the IRC work, will do that today post meeting 14:05:54 but re-action the action item now 14:06:05 #action sayan to create the PR for the IRC work 14:06:50 I did a research of the Python + JS packages to be packaged, but there are a few doubts that I would like to discuss 14:07:47 I created the etherpad page with the list of dates and added to README (will send a PR for this one too) 14:08:13 abompard and I did not sit to discuss on the outreachy proposal 14:08:25 abompard: did you write up anything? 14:08:42 sayan: no :-/ 14:09:09 abompard: ok, we need to write up this week only as I will be on PTO next week 14:09:35 okay. I'm off on Friday, so let's do it tomorrow or Thursday 14:09:40 But I did go through the proposals which wikimedia, and openstack have put in (to get an idea how to write a proposal) 14:09:53 we're definitely short on time for that 14:09:57 abompard: okay, let do it tomorrow 14:10:02 sayan: ok. 14:10:11 mizmo: do you think it's too late? 14:10:41 abompard: no but you'd want everything submitted by the end of this week 14:10:54 #link https://phabricator.wikimedia.org/T174528 14:11:12 this is the proposal from wikimedia 14:12:03 wow yeah it's short. 14:12:07 #action abompard and sayan to collaborate on Wed and discuss the widgets for the outreachy proposal, and draft the outline of the proposal 14:12:58 There are other projects as well here 14:13:00 #link https://phabricator.wikimedia.org/project/view/2957/ 14:13:16 So we can take inspiration, and write one 14:13:56 OK 14:13:57 #topic Status Updates 14:15:16 Last week, I was looking around the projects for deployment of a react project. I sent out a PR moving around the dependencies. 14:15:24 abompard: mizmo: updates from your side? 14:15:33 pagure.issue.comment.edited -- duffy edited a comment on ticket fedora-hubs#283: "Create nick wizard for new IRC users / freenode registration" https://pagure.io 14:16:04 abompard: nothing :( i have been occupied with prepping a keynote for OLF + a BU project 14:16:33 pagure.issue.comment.edited -- duffy edited a comment on ticket fedora-hubs#283: "Create nick wizard for new IRC users / freenode registration" https://pagure.io 14:16:53 pagure.issue.comment.edited -- duffy edited a comment on ticket fedora-hubs#283: "Create nick wizard for new IRC users / freenode registration" https://pagure.io 14:16:55 yeah, about deploying to prod: during my 1x1 with stickster yesterday he suggested that we should make a clear list of the minimal features we want to have before going to prod 14:17:06 I don't think we have that yet 14:17:10 pagure.issue.comment.edited -- duffy edited a comment on ticket fedora-hubs#283: "Create nick wizard for new IRC users / freenode registration" https://pagure.io 14:17:18 abompard: yeah 14:17:29 i think irc is the main thing we want for prod right 14:17:43 mizmo: yes 14:17:44 So I came up with a few things we definitely need, and some that may be optional 14:18:09 mizmo: yeah but it's not only features. For exemple there are still a lot of "placeholder" pages in the current codebase 14:18:18 the "All groups" page is a placeholder 14:18:26 the search bar on top is not connected 14:18:27 etc. 14:18:34 pagure.issue.comment.edited -- duffy edited a comment on ticket fedora-hubs#283: "Create nick wizard for new IRC users / freenode registration" https://pagure.io 14:18:55 ah yes 14:19:03 the "Stream" page, for exemple, has no content 14:19:09 i think tho, both the all groups and search, not criticla if we were doing a small initial pilot group, because they would just be using their one hub 14:19:21 yeah I agree 14:19:22 pagure.issue.comment.edited -- duffy edited a comment on ticket fedora-hubs#283: "Create nick wizard for new IRC users / freenode registration" https://pagure.io 14:19:54 but we should at least track that and put in something clearer than dummy data 14:20:07 so, can we have the meeting like this: rather than status updates, we have discussion on issues. 14:20:16 and also the set of widgets installed by default on a page could use a discussion I think 14:20:31 and issues not like a widget, but a smaller component of a widget than can we worked on 14:20:58 abompard: " and also the set of widgets installed by default on a page could use a discussion I think " -- did not get this one 14:21:14 I'll make tickets for those issues, and we'll decide if they are necessary for prod or not 14:21:36 sayan: basically when a new user connects, their hub is populated with some default widgets 14:21:45 abompard: right 14:21:48 sayan: it's not all widgets, only some of them (in defaults.py) 14:22:09 sayan: I think we should discuss which one are relevant. Defaults are important. 14:22:13 abompard: right, but what you mean by "use a discussion" 14:22:17 Oh ok 14:22:19 got you now 14:22:22 :) 14:22:31 sorry I'm not always clear, thanks for asking 14:22:33 abompard: yeah! 14:23:20 abompard: so you will create issues for the widgets? 14:23:24 probably library widget 14:23:26 irc for PMs 14:23:31 calendar hooked up to their fas calendar 14:24:05 maybe pagure or bz issues assigned to them or if there are none, that they filed? 14:24:09 sayan: yeah I'll create and issue for all topics I think may need to be worked on or discussed before prod 14:24:23 abompard: okay 14:24:37 mizmo: I don't think the bz / pagure widgets can do that currently 14:24:42 * stickster off phone and re-lurks... this discussion of the so-called "MVP" (minimum viable product) is definitely useful... perhaps tagging all the issues that way (or some way) for the prod milestone and having that drive each week of work seems like the right way to go 14:25:15 abompard: we probably want new ones then :-/ 14:25:37 so you can input an email or fas id and get the widgets (bz / pagure respectively) 14:25:44 mizmo: Yeah, they get the tickets assigned to you but not those you filed 14:25:51 im thinking what would be useful for design team members on their stream page 14:26:07 and i think probably a widget with a list of their assigned tickets in the design team pagure would be good 14:26:10 and if they didn't work on any, the ones they have filed or have been involved with would be useful 14:26:24 oh if there is already ones assigned to you, that is probably enough for MVP 14:27:32 #action abompard to create issues on the topics for MVP 14:28:34 Also, I mentioned to sayan that it would be a good idea to start charting a release roadmap. For example, if first prod is 0.1, then maybe try to set some milestone every 6 (?) weeks after and know what issues are going into that... over time, should be possible to drive part of that based on community feedback 14:28:52 like 0.2 has the following fixes/changes; etc. 14:29:29 I will tag the widgets, that we have no plan in working right now with wishlist, and then create a milestone in the pagure to tag the widgets that we need going forward 14:29:30 * stickster totally open to feedback here, if that's a terrible idea 14:29:39 in the next release 14:31:12 and after every release we have a detail thinking on 1-2 widgets to be worked on, broken into different issues and psuh 14:31:19 i think its a good idea but ownership in terms of proj management is a bit up in the air 14:31:21 we dont really have a project manager / wrangler 14:32:39 Is it a requirement to have a separate person for that? 14:32:48 mizmo: yes, since most of the widgets are really big, it would be good to launch a widget every 6 weeks 14:33:16 i dont know that its a requirement but having it be up in the air results in a lot of misdirection 14:33:38 that's a fair point... mizmo, IOW you're asking, who makes the call on what goes into that list for a milestone 14:34:25 what's goes in the next milestone is something totally dependent on which are we focussing on 14:34:47 not even that, more, we kind of have a short memory over time, we've switched methods of tracking these things multiple times (i've done mega triages and tagging for milestones in pagure for hubs tix at least 2x and i know im not the only one) 14:35:33 *nod -- staying focused one method of tracking is kind of important, otherwise it's wasted time 14:36:03 part of that was probably driven by Trac -> Pagure as well 14:36:13 i dont know, i dont really have an answer except for large projects like this that i've been part of in the past went a lot more smoothly when there was some project manager type function with a schedule and milestones, and that schedule was more solid 14:36:29 *nod 14:37:17 of course those projects also had teams of 6+ engs f/t 14:37:55 * mizmo has no answers :( sorry 14:38:04 I guess my feeling is that the team could decide a couple ways to do this: (1) a regular cadence of weeks, and no more than widgets per cadence... (2) just set widgets and fixes per release, and however long it takes to get that done 14:38:19 Selecting the features based on community feedback 14:38:32 that could be decided in one Hubs meeting per cadence period 14:39:00 i think irc is the big block on having a MVP though, and it's a 'widget' for sure but its kind of complicated to break down in that kind of widgets model 14:39:07 anyway, I'm not trying to dictate that, or drag the meeting into a OT discussion, so I'll shut up :-) 14:39:36 yeah, the sizing makes this maybe nonsensical. 14:39:43 i mean maybe we schedule out say 6-8 weeks from now and per week try to schedule a chunk based on everyone's availability 14:39:58 eg sayan, can you think of weekly chunks for irc functionality you could work on for the next 6-8 weeks 14:40:01 in any case, the MVP is really the most important thing and clearly you guys are thinking about it 14:40:39 stickster: it's actually a needed discussion, because a bunch of things are broken in the process now 14:40:59 mizmo: I cannot tell as a whole, the problem is there are so many things to read and connect 14:41:10 sayan: maybe better for a list discussion, so we don't swamp the meeting :-) 14:41:37 sayan: well what is the current status of irc functionality? what works? 14:42:09 stickster: okay 14:42:21 mizmo: right now, the creating of the IRC nicks works 14:42:34 the registratoin flow 14:43:14 https://pagure.io/fedora-h 14:43:17 grr 14:43:21 https://pagure.io/fedora-hubs/issue/283 14:44:38 sayan: is there any way we could take a look or get a demo? 14:45:00 is it pushed to the main repo right now? 14:45:15 mizmo: you have the repo setup? 14:45:29 sayan: i do although on my workstation its pretty out of date 14:45:42 mizmo: you can pull the changes from my branch and run it 14:46:35 sayan: ok, is there a reason it's not in the main branch? 14:46:41 does it need to be rebased or something? 14:47:08 mizmo: so, main branch is the one that is merged via PR 14:47:34 mizmo: by main branch you mean the develop branch in fedora-hubs right? 14:47:42 is it waiting on a PR review? 14:47:48 yep 14:48:39 mizmo: let me send a PR now itself 14:49:22 i think if we have a clear picture of what is done and what is left, maybe in terms of a flat list of functional requirements with the functions that are complete checked off, then we can better understand how to schedule out the missing functionality 14:49:32 i think being able to run / demo how its working now will help 14:50:05 mizmo: thats is the thing I am talking off, there are a few things that I learnt from working on the IRC one 14:50:58 prediction is really difficult, so breaking into really small chunks helps 14:51:07 and smalls chunks to be discussed 14:51:16 mizmo++ 14:51:16 stickster: Karma for duffy changed to 5 (for the f26 release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:52:01 like, we planned about Matrix, now matrix homeserver had to be package, along with the irc-bridge 14:52:36 but since irc-bridge is a js package, there is a huge list of js dependencies 14:53:44 packaging and development can be done side-by-side by different people if necessary 14:54:35 and then in the main work can be divided into three parts (raw irc connection, matrix connection, storing and displaying logs) 14:54:53 packaging is something i think more easily done by volunteers in the broader fedora comm right? 14:55:33 mizmo: we don't have many JS packagers sadly, and during flock I came to know nobody is very enthusiastic about the JS packaging 14:55:56 sayan: whats the issue with js packaging 14:56:00 and is packaging the only way to achieve this 14:56:54 eg what do admins who use ansible to manage their systems do to keep the js libs in their apps up to date? i am guessing they dont rpm package a lot of js? 14:57:03 that's is something that I wanted to dicuss when I said in the beginning of the meeting that I have a doubt with the list of Python + JS packages we have for deploying hubs 14:57:36 mizmo: the issues with js packaging is there is a huge list of them 14:57:55 so what is driving the need to package them? 14:58:06 I'm interested in that discussion too. stickster I suppose you didn't hear something related to that at AnsibleConf? 14:58:52 mizmo: rpm is the way I have been deploying stuffs into Fedora prod boxes 14:58:54 abompard: Do you mean packaging projects that have a lot of bundled libs? 14:58:56 abompard: ^^ 14:59:52 mizmo: but I am looking for alternatives now as I went through the list of all the JS packages we have probably 100s 14:59:54 it continues to be an issue (hi, AWX!) that RPM packaging is a fantastic hammer, but not everything is a nail 15:00:00 yeah, people deploying JS-heavy webapps 15:00:41 stickster: so ansible brings no answers to that conundrum? 15:00:49 sayan: do you think JS packaging is standard enough that we could create the RPMs automatically? 15:01:02 mizmo: I don't know what the question is, exactly 15:01:32 abompard: jsmith told me he is building something 15:01:35 ansible is for automating... it's kind of orthogonal to the packaging or the way things are shipped 15:02:09 i was thinking tho this isnt a unique problem and using ansible to manage a system there must be best practoices when it includes lots of js libraries like this 15:02:11 i have to run i have an 11 15:02:28 mizmo: I think in ansible terms, you'd just deploy it in a container 15:02:44 stickster: but have you heard of a "standard" way of packaging JS libs/apps for prod? 15:02:58 stickster: OK so they just run "npm install" in a container and be done with it? 15:03:09 abompard: I haven't -- doesn't mean there isn't one, but I don't know what it is. 15:03:12 ok 15:03:26 abompard: mizmo: most of the people directly pull from npm 15:04:49 anyway that's a discussion we must have with the rest of the infra team 15:05:25 abompard: that's is something I wanted to dicuss in today's meeting because if we sit down packaging the js packages, we would never end 15:05:30 we need to find alternative 15:05:40 sayan: yeah 15:06:20 abompard: I read through a couple of blogs last week on react deployments and building webpack production builds 15:06:35 but I could not figure out on how it integrates with out current workflow 15:07:35 mizmo: so, like IRC there are bunch of other big issues. so I was wondering that rather than multiple persons working on multiple issues 15:07:54 it would be good to have mutiple people working on a single issue. 15:08:15 that would lead to more interaction, and help building the widget quick 15:08:39 sayan: I think we can delay the packaging aspect for the moment until we find something better that packaging JS libs into RPMs by hand. And we could focus on development. 15:09:10 abompard: yes, I am totally delaying that for now, but like if you can me work on IRC together 15:09:17 then we can finish it quick 15:09:26 sayan: do you mean to say you would like more people to work with you on the IRC widget? 15:09:30 sayan: yeah 15:09:42 sayan: OK, I'll help you, that makes sense 15:09:44 and then do release, and then over the next release cycle we pick another widget and work together 15:10:17 brainstormfirst, create small issues, and then work 15:10:42 in that case, if there is some issues that pops up, atleast there another person to seek help 15:10:49 abompard: ^^ 15:11:17 sayan: since it's in the critical path to prod I think it's justified. I'll need an small intro to the architecture though 15:11:38 abompard: sure 15:12:27 abompard: I will create a PR after the meeting (need to remove a few things from code from default_config.py) 15:12:36 sayan: okay 15:12:39 abompard: and then I can explain the architeture 15:12:55 sayan: I need to create my task tickets anyway 15:13:11 abompard: sure 15:15:01 let's close the meeting and discuss as we are well overtime 15:15:03 #endmeeting