15:01:24 <langdon> #startmeeting modularity_wg
15:01:24 <zodbot> Meeting started Thu May 26 15:01:24 2016 UTC.  The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:24 <zodbot> The meeting name has been set to 'modularity_wg'
15:01:33 * langdon lost his cheatsheet again
15:01:36 <jkaluza> .hi jkaluza
15:01:40 <langdon> .hello langdon
15:01:42 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com>
15:01:43 <jkaluza> .hello jkaluza
15:01:44 * threebean 
15:01:44 <zodbot> jkaluza: jkaluza 'Jan Kaluža' <jkaluza@redhat.com>
15:01:47 <contyk> .hello psabata
15:01:47 <geppetto> .hello james
15:01:47 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:01:53 <zodbot> geppetto: james 'James Antill' <james.antill@redhat.com>
15:02:24 <jkurik> .hello jkurik
15:02:24 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
15:02:41 <langdon> #link http://piratepad.nl/modularity-wg-agendas < agenda
15:02:49 <langdon> ^^ please add to it if you like
15:04:00 <tflink> .hello tflink
15:04:01 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
15:04:06 <langdon> #Chair dgilmore, cydrobolt, harald, jkurik, langdon, mikedep333, sct, tflink, threebean
15:04:06 <zodbot> Current chairs: cydrobolt dgilmore harald jkurik langdon mikedep333 sct tflink threebean
15:04:20 <langdon> #topic agenda
15:04:41 <langdon> today we plan to talk about: status update from last time and how to get them out better
15:04:55 <langdon> proposal for "whats for flock" board
15:05:00 <langdon> and then open floor
15:05:07 <langdon> unless someone adds something as we go
15:05:20 <tflink> has the meeting time issue been figured out?
15:05:31 <tflink> or are we sticking with this time?
15:05:35 <langdon> tflink, no.. still on my list but haven't sorted it yet
15:05:39 <tflink> k
15:05:56 <langdon> right now i just haven't been able to make it better.. i should probably delegate..
15:06:03 <langdon> anyone want to volunteer?
15:06:26 <jkurik> langdon: yes, I can be the volunteer
15:06:34 <langdon> my best guess is to do two times.. alternating weeks.. then we get half and half
15:06:40 <langdon> jkurik, woot! done!
15:06:56 <langdon> #action jkurik to figure out new meeting time to stop gating on langdon
15:07:16 <langdon> jkurik, ping me offline if you need any info that you don't have
15:07:29 <langdon> any other agenda thoughts?
15:07:38 <jkurik> langdon: ok, I will start on Monday to do so
15:08:16 <langdon> jkurik, cool.. just fyi.. m is a holiday in US.. and, i may be around... but i may also be chaperoning soccer tournament.. if they do well sat/sun ;)
15:08:33 <langdon> s/soccer/futbol ;)
15:08:41 <langdon> ok.. next stopic
15:08:43 <jkurik> :)
15:08:53 <langdon> #topic status update, and how to get them more timely
15:09:31 <langdon> so.. yeah.. again .. gating on me.. and, first i would like to just drop in .. demos are done from sprint 5, and published, i just didn't get to annc'ing yet.. so..
15:09:40 <langdon> this is going to be a long c/p .. fair warning
15:10:14 <langdon> they are in youtube.. but also avail on fp.o if you would prefer not to use proprietary stuff..
15:10:16 <langdon> Sprint Five Demos:
15:10:16 <langdon> http://bit.ly/fed-mod-yt sprint demos
15:10:16 <langdon> OR
15:10:16 <langdon> https://fedorapeople.org/groups/modularity/sprint-5-demo/sprint5demo-threebean.ogv
15:10:16 <langdon> https://fedorapeople.org/groups/modularity/sprint-5-demo/sprint5demo-contyk.ogv
15:10:17 <langdon> https://fedorapeople.org/groups/modularity/sprint-5-demo/sprint5demo-jkaluza-fm-update.ogv
15:10:19 <langdon> https://fedorapeople.org/groups/modularity/sprint-5-demo/sprint5demo-nils.ogv
15:10:21 <langdon> https://fedorapeople.org/groups/modularity/sprint-5-demo/sprint5demo-cpacheco-fm-metadata-service.avi
15:10:24 <langdon> https://fedorapeople.org/groups/modularity/sprint-5-demo/sprint5demo-jkaluza-status-report.ogv
15:10:26 <langdon> https://fedorapeople.org/groups/modularity/sprint-5-demo/sprint5demo-geppetto-jenkings-api-demo.ogv
15:10:28 <langdon> https://fedorapeople.org/groups/modularity/sprint-5-demo/sprint5demo-lkocman.mp4
15:10:49 <langdon> #info please see meeting log directly above for individual links to demos
15:11:00 <langdon> #link http://bit.ly/fed-mod-yt sprint demos
15:11:18 <dgilmore> hola
15:11:19 <langdon> comments thoughts on ^^ ? or more status stuff?
15:12:12 <langdon> ok.. also.. i think we are getting pretty comfortable with https://fedoraproject.org/wiki/Modularization/Infra .. but would really like more comments/feedback particularly from fedora-infra
15:12:18 * contyk still hopes the sprint 4 demo will be published as well
15:12:26 <langdon> #link https://fedoraproject.org/wiki/Modularization/Infra proposed module release arch
15:12:26 <threebean> langdon: that's on me to follow up with them.
15:12:44 <langdon> threebean, yeah.. but hoping i can encourage lots of people to look ;)
15:12:52 <langdon> contyk, yeah yeah..
15:12:56 <langdon> almost to that topic :)
15:13:07 <threebean> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/FBHIMT3E4H4SNLDTPPWOYPYYBIBENCWZ/
15:13:26 <langdon> threebean, i think you are a chair if you want to #link that
15:13:52 <dgilmore> langdon: urls automatically get linked
15:14:05 <threebean> yeah, it auto-links for bare urls.
15:14:05 <langdon> dgilmore, but no context, right?
15:14:22 <langdon> i like the #link because you can also say what it is
15:14:22 <dgilmore> langdon: just has the url
15:14:43 <threebean> #link some infra ideas sent out to the fedora infra list https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/FBHIMT3E4H4SNLDTPPWOYPYYBIBENCWZ/
15:15:00 <langdon> ok.. so in an effort to get status reports out in a more timely fashion.. i am going to ask some of the people working on stuff to take it on as a "sprint task" each week..
15:15:21 <langdon> cause apparently .. i can't get them done fast enough..
15:15:40 <langdon> i would also ask them to set the agenda (really gather feedback on what the agenda is)..
15:16:04 <langdon> so.. please feel free to hassle me if we aren't getting status reports/meeting minutes out in a timely fashion
15:16:26 <langdon> any other thoughts on the above?
15:16:58 <langdon> ok.. next topic then..
15:17:08 * langdon digs for cheatsheet again
15:17:24 <langdon> #topic proposal to start a new "what's for flock" board
15:18:33 <langdon> so.. as the project has progressed, we are noticing a lot of "clutter" on the boards .. and, while we could archive them all and start over.. i think we might find it easier to start with fresh content.. in particular with the stuff we want to deliver by flock..
15:18:58 <langdon> so.. i have in mind two themes that we want to be able to accomplish for flock..
15:19:21 <langdon> #info theme-1 for flock release: Fedora contributors know what modules are
15:19:31 <langdon> and
15:19:38 <langdon> #info theme-2 for flock release: Fedora contributors can build a module
15:20:03 <langdon> so.. in agile land we should probably call those "initiatives" maybe .. but i like the word "theme"..
15:20:50 <langdon> so .. basically the first one is, we have good docs on what a module is, how to define it, what it means, etc and we have started/implemented more of an outreach plan to get it in to the community aside from just #fedora-modularization
15:21:34 <langdon> the 2nd is.. any fedora contributor can 1) know how to "write" a module 2) get the module built 3) tell their friends that they can install it
15:21:45 <langdon> comments? thoughts? not clear enough?
15:21:56 <langdon> theme 3?
15:22:23 <jkurik> langdon: is there going to be a demo on Flock how to do the theme-2 ?
15:22:24 <dgilmore> langdon: how we we deliver them? and how will they be consumed
15:22:32 <contyk> points 2 and 3 of the second theme aren't possibly right now but hopefully wil be by August
15:23:17 <langdon> jkurik, yeah... i imagine that is what my talk will largely be.. i wanted to propose a workshop too but we weren't sure if we would have enough people there.. but now i think we will... so, we should probably follow up with the flock-organizers to see if we can add a "workshop"
15:23:40 <contyk> that'd be cool
15:24:31 <jkurik> +1
15:24:46 <langdon> dgilmore, assuming you are mostly talking about t-2 .. cause i think t-1 is pretty easy/obvious.. i am hoping that wherever possible the "stg.fp.o" version of the things in threebean's arch are implemented to at least a alpha/beta level.. and where there isn't an analogue, we host that on fed-mod.org
15:25:39 <langdon> so.. basically.. everything hosted on fed-mod.org except where we can get the changes in to stg.fp.o
15:25:46 <dgilmore> langdon: stg.fp.o is generally non functional, we are trying to fix that.
15:26:08 <langdon> dgilmore, but, conceptually, does it make sense?
15:26:14 <threebean> heh, yup.  i was telling the about the lack of a 'master mirror' there yesterday.
15:26:36 <dgilmore> langdon: not sure, not sure what fed-mod.org
15:26:36 <threebean> dgilmore: we've successfully used stg pkgdb and stg dist-git so far..
15:26:47 <dgilmore> langdon: none of stage is mirrored
15:26:57 <dgilmore> its really designed around testing changes
15:27:04 <dgilmore> not building and delivering things
15:27:07 <langdon> yeah.. so good example.. we might have fed-mod.org/master-mirror that acts like the stg.fp.o but is just kinda hacked in to the process
15:27:33 <langdon> fed-mod.org is just the dns on a random server we set up..
15:27:55 * dgilmore does not really like random servers
15:28:00 <contyk> :)
15:28:06 <langdon> currently we have doc gen jobs and reporting sitting on there.. including a "sharable fm-server"
15:28:07 <contyk> it's for development
15:28:11 <dgilmore> langdon: https://fedoraproject.org/wiki/ReleaseEngineering/PriorityPipeline#F25_Planned_Rel-Eng_Deliverable_Changes we have on our list of things to evaluate, modules
15:28:34 <langdon> contyk, right..
15:29:03 <langdon> dgilmore, well.. i think the hope is.. the changes are fully compat with existing work.. so this would be things "next to" the main pipeline..
15:29:29 <langdon> and the module-pipeline would be purely unsupported.. just a way to get people's feet wet..
15:29:58 <langdon> i would just like it to live as close to the "real" infra as possible.. cause, as you say, random-server = bad
15:30:08 <dgilmore> langdon: I would like something a little less whishy washy and a bit more concrete
15:30:38 <dgilmore> and work out how we get things into the toolinga nd workflows and not be this random thing off to the side
15:30:54 <langdon> so.. i laughed.. because i think i know what you mean.. but to be clear.. in what way? like a plan? or a "deployed arch"? or both?
15:31:02 * tflink would also like to know more details about what automation is needed
15:31:17 * langdon points at threebean
15:31:21 <tflink> so we're not in a "we needed this last week!" kind of situation
15:31:23 * threebean walks out of the room
15:31:35 <dgilmore> langdon: A plan, something we can implement to deliver a few modules
15:31:52 <dgilmore> something that provides a footing to build on and expand
15:31:58 <threebean> https://fedoraproject.org/wiki/Modularization/Infra
15:32:03 <threebean> ^^ I think that's the starting point for that discussion
15:32:09 <threebean> we want to build module content in koji.
15:32:12 <contyk> +1
15:32:18 <threebean> we want to automate rebuilds with a workflow thing sitting outside of koji.
15:32:19 <tflink> how much of that is planned for august?
15:32:22 <langdon> so.. this is entirely about doing a slow migration.. and basically adding things to the pipeline as we go.. rather then ever having to do a "cutover" or gating on "omg we needed this last week"
15:32:37 <threebean> we want to hand off stuff to taskotron to evaluate each build and halt the chain rebuild if stuff fails
15:32:41 <threebean> we want to compose with pungi
15:32:45 <threebean> we want to store data in PDC.
15:32:58 <threebean> there's a lot of pieces.. and we have much more detail on some of them than others.
15:33:18 <langdon> but it is more about getting the flow between systems right... rather than the details of the system..
15:33:22 <threebean> exactly *how* we want to test modules in taskotron is a big gap.  we don't have much of anything concrete there yet (sorry, tflink :/)
15:33:29 <langdon> for example, it flows to taskotron but there are no tests
15:33:36 <threebean> bingo
15:33:51 <dgilmore> well I see this as extra deliverables, and we will build install media and lives etc exactly as we do today at least for some foreseeable future.  People can opt it to doing things in a modular way
15:33:52 <tflink> is the plan still to only test on builds?
15:34:08 <threebean> dgilmore: +1
15:34:12 <contyk> tflink: nope, we definitely need to test modules before we push them to mirrors
15:34:20 <threebean> dgilmore: we don't want to "compose the distribution from modules" for f25.
15:34:26 <dgilmore> we do not have to make everything in modules available in teh old way, and we do not need to deliver all the old artifacts in a modular way going forward
15:34:29 <contyk> tflink: it's not in the diagram but I think it's mentioned in the open questions section
15:34:40 <langdon> tflink, no.. i think you raised a good point on that (last week, maybe?) .. but this is kinda the point.. we want the flows going where things "would happen" and then we start to fill in the "it actually happens"
15:34:50 <dgilmore> threebean: not saying that it is
15:34:56 * threebean nods
15:35:59 <dgilmore> langdon: I guess the question really is when do we plan to ship some modules as an official part of fedora
15:36:09 <threebean> tflink, contyk: note that, we're not asking taskotron devs to devise a way to test modules as modules on any kind of timeframe.  we actually have a bunch of handy people running around the modularity working group, so we'll try to organize some to come knock on your door to help with implementation.  (same goes for the other tools in our pipeline)
15:36:11 <langdon> well.. i might argue that point.. i guess i kinda see "some day" .. that if fedora-server-f26 doesn't really care about the benefits of modules.. they can still distribute an edition exactly like f23 .. but that the infra that builds that edition is actually based on modules
15:36:16 <tflink> langdon: sure, I'm not asking "why haven't the tests been written?". it's more of a "when and in response to what events will checks need to be run?" and "are there any ideas of the kinds of things which will be needed to write the checks people have in mind?"
15:36:57 <langdon> dgilmore, on that front.. im thinking f26? perhaps during the f25 lifecycle? if we can figure out how to "ship a module on existing fedora"
15:37:01 <dgilmore> langdon: I guess I do not see it the same way
15:37:41 <dgilmore> langdon: in that if the server dvd is to be built and shipped the same way there is no modules involved at all
15:37:44 <contyk> doing both would require the current contributors to do too much work
15:38:03 <contyk> since we expect the package maintainers to actually create and maintain modules
15:38:03 <dgilmore> contyk: how?
15:38:10 <bconoboy> dgilmore: it seems like it's too early to talk about shipping modules aas an official part of fedora.  clearly that is the goal but are we really far enough along to discuss the details?
15:38:29 <langdon> dgilmore, can you elaborate? like why not? i guess i don't see a value to doing a "cutover".. and using the modulartiy-proposed infrastructure would still benefit a non-module-release
15:39:07 <dgilmore> bconoboy: perhaps it is too early
15:39:16 <langdon> contyk, unless significantly more of the spec file/module-definition work is automated
15:39:22 <dgilmore> langdon: I am not talking about doing a cutover
15:39:36 <bconoboy> dgilmore: this would be a great topic for flock though, if we're far enough along then
15:40:00 <langdon> dgilmore, to your and bconoboy's point.. lets talk about that at flock.. i think that should be the right timeframe..
15:40:07 <dgilmore> langdon: sure
15:40:18 <dgilmore> I will take modules off of the releng view for f25
15:40:49 <langdon> for now.. this is just.. can we bolt a bunch of the modularity stuff on to the side of the stg infra so we get the not-random-server benefit and the people-know-how-to-interact-with-it benefit..
15:41:15 <dgilmore> langdon: we would need to make stage less broken
15:41:18 <dgilmore> but sure
15:41:36 <langdon> luckily we might have some people who can help with that :)
15:41:44 <contyk> langdon: updating spec files and yamls isn't the most difficult part -- it's maintaining package branches and modules just add additional branches to the current FedoraN, N-1 and N-2 (and optionally EPEL)
15:42:00 <langdon> contyk, right... yeah.. automating that too
15:42:15 <contyk> heh
15:42:36 <dgilmore> contyk: I guess the question is do we need F-XX EPEL-XX if we have modules
15:42:40 <langdon> that is kinda what i mean about "module infra" may be simpler to maintain /work with than existing .. even if shipping a tradition release
15:42:56 <langdon> *traditional
15:43:10 <contyk> dgilmore: indeed, I don't think we do
15:43:14 <dgilmore> in that say httpd opts into modules they pick one version to be the tarditional supported one and build that in the f26 tags
15:43:42 <langdon> dgilmore, so we don't for the modules (per se) .. but.. can we generate them from the module-model so that the old paths still work.. but we get some of the simplicity of the module model
15:43:43 <contyk> dgilmore: I don't like the idea of doing both the classic releases and modules for the same components
15:44:07 <dgilmore> langdon: not sure what you mean by that
15:44:25 <dgilmore> contyk: I see it is required for some period of time
15:44:37 <contyk> dgilmore: sure, temporary is fine
15:45:08 <contyk> we can build a modular release in parallel to the classic piece
15:45:09 <langdon> but the releases are "just" packaging.. right.. like the binaries are the same.. whether dnf puts them on disk as a module, an rpm, a gem, a whatever.. the source & binary are the same.. so we just need to present a view to the release infrastructure that looks like what it expects
15:46:01 <contyk> langdon: the buildroots could be different, the git commits people actually build can be different too
15:46:04 <langdon> in other words.. and put *very* simplistically.. we don't *actually* need a branch for epel.. we need all the things that consume it to access it as if it were a branch
15:46:06 <dgilmore> langdon: maybe
15:46:21 <dgilmore> the sources could be the same but the binaries differ
15:46:37 <dgilmore> when built as a module something extra is enmabled/disabled for instance
15:46:45 <contyk> yes
15:46:48 <langdon> dgilmore, contyk right.. i don't disagree... the buildroots are hard.. but I still think "manufacturable"
15:47:12 <contyk> langdon: one of the feature we have is that the module packager defines their own buildroot
15:47:35 <contyk> from the scratch
15:47:45 * dgilmore is interested to know how that will work
15:48:05 <langdon> but.. a topic for another day.. i think.. basically.. i am pushing to find a way for our existing release model to be shippable from a module based infrastructure because I think it will be 1) way less risky 2) way less disruptive.. then, once people see the benefits of modularity, they can start to abandon the old delivery choices
15:48:51 <langdon> so.. i don't think there aren't problems.. and i don't think it is easy.. but, i do think it is doable.. and i think it is worthwhile
15:49:19 <langdon> but.. like .. not just a part of the wg conversation.. this is a major part of the "work" .. to solve this, i mean
15:49:44 <langdon> ok.. good to move on a bit?
15:49:47 <dgilmore> langdon: a lot of issues to solve
15:49:52 <dgilmore> sure
15:50:13 <langdon> dgilmore, thats why i have contyk & threebean .. they promised me earlier they would solve all the problems ;)
15:50:21 <contyk> ;)
15:50:29 <contyk> I dare to say we'll have *something* for Flock
15:50:35 <langdon> ha
15:51:04 <dgilmore> langdon: whiskey solves them also
15:51:05 <langdon> ok.. so we are gonna put up a new board.. and we think we may do it in trello.. because a bunch of the missing features in taiga are hurting us..
15:51:08 <contyk> we'll see if it will be worth expanding then
15:51:12 <langdon> dgilmore, but only for a short time
15:51:14 <langdon> :)
15:51:45 <contyk> trello's not free (as in freedom)
15:51:58 <contyk> and we cannot host it on fedora infra
15:52:29 <langdon> yeah.. so i also want to start a "doc" that has what is missing.. so we can work on that .. so like use trello while the punch list gets fixed.. then switch back..
15:52:58 <langdon> contyk, make sense?
15:53:23 <contyk> sense, yes; do I like that? no
15:53:30 <contyk> what features are we missing?
15:53:33 <langdon> basically... there are a LOT of helper tools for trello .. that we would like to use.. that don't exist for taiga.. and we don't want to port them right this minute
15:53:37 <dgilmore> ^ what he said
15:53:37 <contyk> I find taiga having more features than trello
15:53:59 <dgilmore> contyk: that is
15:54:30 <langdon> contyk, well.. it may be worth having a longer discussion in #fed-mod.. i don't think this is set in stone (or permanent even if we switch for a time)
15:54:51 <langdon> we do have sync'ing between trello/taiga.. so we are capturing our data there
15:54:57 <langdon> *are NOT  :)
15:55:18 <langdon> contyk, make sense?
15:55:36 <langdon> like table to discuss in #fed-mod? jkaluza has way more detail than me
15:55:55 <contyk> sure, we can discuss it there
15:56:00 <contyk> although I doubt I would budge on this
15:56:08 <langdon> i just want to give the 5 mins for open floor
15:56:14 * dgilmore needs to run in a sec.
15:56:23 <jkaluza> I think we should start with that doc what's missing on Taiga and then decide
15:56:27 <jkaluza> *in
15:56:41 <langdon> jkaluza, ok
15:56:41 <jkaluza> When thinking about it now... :)
15:56:56 <jkaluza> you can give it as action item to me
15:57:03 <langdon> #agreed review challenges in taiga management, document, start project to fix
15:57:09 <langdon> #undo
15:57:09 <zodbot> Removing item from minutes: AGREED by langdon at 15:57:03 : review challenges in taiga management, document, start project to fix
15:57:13 <langdon> did that make sense?
15:57:39 <langdon> should i just action it to you (jkaluza) or do an #agreed?
15:58:20 <langdon> actually how about #action to jkaluza to bring a proposal asap to the team .. preferably before next wg meeting
15:58:26 <jkaluza> I will be going through all the sprint tools anyway, so I can write what we are missing in taiga
15:58:30 <jkaluza> yes, I'm OK with that
15:59:11 <langdon> #action jkaluza to identify gaps in taiga itself and the tooling-ecosystem and propose solutions to ML for discussion
15:59:17 <langdon> ok
15:59:18 <jkaluza> +1
15:59:24 <langdon> for 1 m of open floor ;)
15:59:25 <langdon> #topic open floor
15:59:30 <langdon> anything anybody?
15:59:42 * jkurik has nothing more
15:59:57 <langdon> or we can keep talking about the beauties of ecosystem-locking
16:00:03 <langdon> *ecosystem-lockin
16:00:37 <langdon> ok.. we are at time any way.. so .. going once?
16:00:46 <langdon> going twice?
16:00:58 <langdon> going three times?
16:01:02 <langdon> ok
16:01:05 <langdon> #endmeeting