14:01:49 <sayan> #startmeeting hubs-devel
14:01:49 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:49 <zodbot> The meeting name has been set to 'hubs-devel'
14:01:50 <abompard> it's here !
14:02:27 <sayan> #topic roll call
14:02:32 <sayan> .hello sayanchowdhury
14:02:34 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
14:02:43 <stickster> .hello pfrields
14:02:44 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
14:02:47 <mizmo> .hello duffy
14:02:47 <abompard> .hello abompard
14:02:47 <zodbot> mizmo: duffy 'Máirín Duffy' <fedora@linuxgrrl.com>
14:02:50 <zodbot> abompard: abompard 'Aurelien Bompard' <aurelien@bompard.org>
14:02:56 <sayan> #chair stickster abompard mizmo
14:02:56 <zodbot> Current chairs: abompard mizmo sayan stickster
14:03:49 <sayan> #topic Action items from the last meeting
14:03:55 <sayan> sayan to create the PR for the IRC work
14:03:57 <sayan> sayan to create a issue to track all the libraries (Python + JS) to be packaged
14:03:59 <sayan> mizmo to create easyfix bounties for hubs
14:04:01 <sayan> abompard and sayan to discuss the widgets for the outreachy proposal, and draft the outline of the proposal
14:04:03 <sayan> sayan to create a etherpad page with the list of dates, and add it to the readme
14:04:30 <mizmo> 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 <sayan> Yeah, we decided that during last meeting itself
14:05:34 <mizmo> +1
14:05:45 <sayan> I did not get time to create the PR for the IRC work, will do that today post meeting
14:05:54 <sayan> but re-action the action item now
14:06:05 <sayan> #action sayan to create the PR for the IRC work
14:06:50 <sayan> 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 <sayan> 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 <sayan> abompard and I did not sit to discuss on the outreachy proposal
14:08:25 <sayan> abompard: did you write up anything?
14:08:42 <abompard> sayan: no :-/
14:09:09 <sayan> abompard: ok, we need to write up this week only as I will be on PTO next week
14:09:35 <abompard> okay. I'm off on Friday, so let's do it tomorrow or Thursday
14:09:40 <sayan> 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 <mizmo> we're definitely short on time for that
14:09:57 <sayan> abompard: okay, let do it tomorrow
14:10:02 <abompard> sayan: ok.
14:10:11 <abompard> mizmo: do you think it's too late?
14:10:41 <mizmo> abompard: no but you'd want everything submitted by the end of this week
14:10:54 <sayan> #link https://phabricator.wikimedia.org/T174528
14:11:12 <sayan> this is the proposal from wikimedia
14:12:03 <abompard> wow yeah it's short.
14:12:07 <sayan> #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 <sayan> There are other projects as well here
14:13:00 <sayan> #link https://phabricator.wikimedia.org/project/view/2957/
14:13:16 <sayan> So we can take inspiration, and write one
14:13:56 <abompard> OK
14:13:57 <sayan> #topic Status Updates
14:15:16 <sayan> 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 <sayan> abompard: mizmo: updates from your side?
14:15:33 <fm-hubs_> 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 <mizmo> abompard: nothing :( i have been occupied with prepping a keynote for OLF + a BU project
14:16:33 <fm-hubs_> 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 <fm-hubs_> 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 <abompard> 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 <abompard> I don't think we have that yet
14:17:10 <fm-hubs_> 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 <sayan> abompard: yeah
14:17:29 <mizmo> i think irc is the main thing we want for prod right
14:17:43 <sayan> mizmo: yes
14:17:44 <abompard> So I came up with a few things we definitely need, and some that may be optional
14:18:09 <abompard> 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 <abompard> the "All groups" page is a placeholder
14:18:26 <abompard> the search bar on top is not connected
14:18:27 <abompard> etc.
14:18:34 <fm-hubs_> 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 <mizmo> ah yes
14:19:03 <abompard> the "Stream" page, for exemple, has no content
14:19:09 <mizmo> 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 <abompard> yeah I agree
14:19:22 <fm-hubs_> 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 <abompard> but we should at least track that and put in something clearer than dummy data
14:20:07 <sayan> so, can we have the meeting like this: rather than status updates, we have discussion on issues.
14:20:16 <abompard> and also the set of widgets installed by default on a page could use a discussion I think
14:20:31 <sayan> and issues not like a widget, but a smaller component of a widget than can we worked on
14:20:58 <sayan> 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 <abompard> I'll make tickets for those issues, and we'll decide if they are necessary for prod or not
14:21:36 <abompard> sayan: basically when a new user connects, their hub is populated with some default widgets
14:21:45 <sayan> abompard: right
14:21:48 <abompard> sayan: it's not all widgets, only some of them (in defaults.py)
14:22:09 <abompard> sayan: I think we should discuss which one are relevant. Defaults are important.
14:22:13 <sayan> abompard: right, but what you mean by "use a discussion"
14:22:17 <sayan> Oh ok
14:22:19 <sayan> got you now
14:22:22 <abompard> :)
14:22:31 <abompard> sorry I'm not always clear, thanks for asking
14:22:33 <sayan> abompard: yeah!
14:23:20 <sayan> abompard: so you will create issues for the widgets?
14:23:24 <mizmo> probably library widget
14:23:26 <mizmo> irc for PMs
14:23:31 <mizmo> calendar hooked up to their fas calendar
14:24:05 <mizmo> maybe pagure or bz issues assigned to them or if there are none, that they filed?
14:24:09 <abompard> 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 <sayan> abompard: okay
14:24:37 <abompard> 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 <mizmo> abompard: we probably want new ones then :-/
14:25:37 <mizmo> so you can input an email or fas id and get the widgets (bz / pagure respectively)
14:25:44 <abompard> mizmo: Yeah, they get the tickets assigned to you but not those you filed
14:25:51 <mizmo> im thinking what would be useful for design team members on their stream page
14:26:07 <mizmo> and i think probably a widget with a list of their assigned tickets in the design team pagure would be good
14:26:10 <mizmo> and if they didn't work on any, the ones they have filed or have been involved with would be useful
14:26:24 <mizmo> oh if there is already ones assigned to you, that is probably enough for MVP
14:27:32 <sayan> #action abompard to create issues on the topics for MVP
14:28:34 <stickster> 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 <stickster> like 0.2 has the following fixes/changes; etc.
14:29:29 <sayan> 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 <sayan> in the next release
14:31:12 <sayan> 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 <mizmo> i think its a good idea but ownership in terms of proj management is a bit up in the air
14:31:21 <mizmo> we dont really have a project manager / wrangler
14:32:39 <stickster> Is it a requirement to have a separate person for that?
14:32:48 <sayan> mizmo: yes, since most of the widgets are really big, it would be good to launch a widget every 6 weeks
14:33:16 <mizmo> i dont know that its a requirement but having it be up in the air results in a lot of misdirection
14:33:38 <stickster> 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 <sayan> what's goes in the next milestone is something totally dependent on which are we focussing on
14:34:47 <mizmo> 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 <stickster> *nod -- staying focused one method of tracking is kind of important, otherwise it's wasted time
14:36:03 <stickster> part of that was probably driven by Trac -> Pagure as well
14:36:13 <mizmo> 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 <stickster> *nod
14:37:17 <mizmo> of course those projects also had teams of 6+ engs f/t
14:37:55 * mizmo has no answers :( sorry
14:38:04 <stickster> I guess my feeling is that the team could decide a couple ways to do this: (1) a regular cadence of <N> weeks, and no more than <X> widgets per cadence... (2) just set <X> widgets and <Y> fixes per release, and however long it takes to get that done
14:38:19 <stickster> Selecting the features based on community feedback
14:38:32 <stickster> that could be decided in one Hubs meeting per cadence period
14:39:00 <mizmo> 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 <x> widgets model
14:39:07 <stickster> anyway, I'm not trying to dictate that, or drag the meeting into a OT discussion, so I'll shut up :-)
14:39:36 <stickster> yeah, the sizing makes this maybe nonsensical.
14:39:43 <mizmo> 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 <mizmo> eg sayan, can you think of weekly chunks for irc functionality you could work on for the next 6-8 weeks
14:40:01 <stickster> in any case, the MVP is really the most important thing and clearly you guys are thinking about it
14:40:39 <sayan> stickster: it's actually a needed discussion, because a bunch of things are broken in the process now
14:40:59 <sayan> mizmo: I cannot tell as a whole, the problem is there are so many things to read and connect
14:41:10 <stickster> sayan: maybe better for a list discussion, so we don't swamp the meeting :-)
14:41:37 <mizmo> sayan: well what is the current status of irc functionality? what works?
14:42:09 <sayan> stickster: okay
14:42:21 <sayan> mizmo: right now, the creating of the IRC nicks works
14:42:34 <sayan> the registratoin flow
14:43:14 <mizmo> https://pagure.io/fedora-h
14:43:17 <mizmo> grr
14:43:21 <mizmo> https://pagure.io/fedora-hubs/issue/283
14:44:38 <mizmo> sayan: is there any way we could take a look or get a demo?
14:45:00 <mizmo> is it pushed to the main repo right now?
14:45:15 <sayan> mizmo: you have the repo setup?
14:45:29 <mizmo> sayan: i do although on my workstation its pretty out of date
14:45:42 <sayan> mizmo: you can pull the changes from my branch and run it
14:46:35 <mizmo> sayan: ok, is there a reason it's not in the main branch?
14:46:41 <mizmo> does it need to be rebased or something?
14:47:08 <sayan> mizmo: so, main branch is the one that is merged via PR
14:47:34 <sayan> mizmo: by main branch you mean the develop branch in fedora-hubs right?
14:47:42 <mizmo> is it waiting on a PR review?
14:47:48 <mizmo> yep
14:48:39 <sayan> mizmo: let me send a PR now itself
14:49:22 <mizmo> 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 <mizmo> i think being able to run / demo how its working now will help
14:50:05 <sayan> 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 <sayan> prediction is really difficult, so breaking into really small chunks helps
14:51:07 <sayan> and smalls chunks to be discussed
14:51:16 <stickster> mizmo++
14:51:16 <zodbot> stickster: Karma for duffy changed to 5 (for the f26 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:52:01 <sayan> like, we planned about Matrix, now matrix homeserver had to be package, along with the irc-bridge
14:52:36 <sayan> but since irc-bridge is a js package, there is a huge list of js dependencies
14:53:44 <abompard> packaging and development can be done side-by-side by different people if necessary
14:54:35 <sayan> and then in the main work can be divided into three parts (raw irc connection, matrix connection, storing and displaying logs)
14:54:53 <mizmo> packaging is something i think more easily done by volunteers in the broader fedora comm right?
14:55:33 <sayan> 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 <mizmo> sayan: whats the issue with js packaging
14:56:00 <mizmo> and is packaging the only way to achieve this
14:56:54 <mizmo> 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 <sayan> 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 <sayan> mizmo: the issues with js packaging is there is a huge list of them
14:57:55 <mizmo> so what is driving the need to package them?
14:58:06 <abompard> I'm interested in that discussion too. stickster I suppose you didn't hear something related to that at AnsibleConf?
14:58:52 <sayan> mizmo: rpm is the way I have been deploying stuffs into Fedora prod boxes
14:58:54 <stickster> abompard: Do you mean packaging projects that have a lot of bundled libs?
14:58:56 <sayan> abompard: ^^
14:59:52 <sayan> 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 <stickster> it continues to be an issue (hi, AWX!) that RPM packaging is a fantastic hammer, but not everything is a nail
15:00:00 <abompard> yeah, people deploying JS-heavy webapps
15:00:41 <mizmo> stickster: so ansible brings no answers to that conundrum?
15:00:49 <abompard> sayan: do you think JS packaging is standard enough that we could create the RPMs automatically?
15:01:02 <stickster> mizmo: I don't know what the question is, exactly
15:01:32 <sayan> abompard: jsmith told me he is building something
15:01:35 <stickster> ansible is for automating... it's kind of orthogonal to the packaging or the way things are shipped
15:02:09 <mizmo> 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 <mizmo> i have to run i have an 11
15:02:28 <stickster> mizmo: I think in ansible terms, you'd just deploy it in a container
15:02:44 <abompard> stickster: but have you heard of a "standard" way of packaging JS libs/apps for prod?
15:02:58 <abompard> stickster: OK so they just run "npm install" in a container and be done with it?
15:03:09 <stickster> abompard: I haven't -- doesn't mean there isn't one, but I don't know what it is.
15:03:12 <abompard> ok
15:03:26 <sayan> abompard: mizmo: most of the people directly pull from npm
15:04:49 <abompard> anyway that's a discussion we must have with the rest of the infra team
15:05:25 <sayan> 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 <sayan> we need to find alternative
15:05:40 <abompard> sayan: yeah
15:06:20 <sayan> abompard: I read through a couple of blogs last week on react deployments and building webpack production builds
15:06:35 <sayan> but I could not figure out on how it integrates with out current workflow
15:07:35 <sayan> 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 <sayan> it would be good to have mutiple people working on a single issue.
15:08:15 <sayan> that would lead to more interaction, and help building the widget quick
15:08:39 <abompard> 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 <sayan> abompard: yes, I am totally delaying that for now, but like if you can me work on IRC together
15:09:17 <sayan> then we can finish it quick
15:09:26 <abompard> sayan: do you mean to say you would like more people to work with you on the IRC widget?
15:09:30 <abompard> sayan: yeah
15:09:42 <abompard> sayan: OK, I'll help you, that makes sense
15:09:44 <sayan> and then do release, and then over the next release cycle we pick another widget and work together
15:10:17 <sayan> brainstormfirst, create small issues, and then work
15:10:42 <sayan> in that case, if there is some issues that pops up, atleast there another person to seek help
15:10:49 <sayan> abompard: ^^
15:11:17 <abompard> 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 <sayan> abompard: sure
15:12:27 <sayan> abompard: I will create a PR after the meeting (need to remove a few things from code from default_config.py)
15:12:36 <abompard> sayan: okay
15:12:39 <sayan> abompard: and then I can explain the architeture
15:12:55 <abompard> sayan: I need to create my task tickets anyway
15:13:11 <sayan> abompard: sure
15:15:01 <sayan> let's close the meeting and discuss as we are well overtime
15:15:03 <sayan> #endmeeting