15:01:39 <langdon> #startmeeting modularity wg
15:01:39 <zodbot> Meeting started Thu Apr  7 15:01:39 2016 UTC.  The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:39 <zodbot> The meeting name has been set to 'modularity_wg'
15:02:03 <langdon> #chairs langdon bconoboy
15:02:12 <bconoboy> \o/
15:02:19 <geppetto> Hey
15:02:24 <langdon> #topic roll call
15:02:28 <mjw> hi
15:02:30 <langdon> .hello langdon
15:02:32 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com>
15:02:45 <nils> .hello nphilipp
15:02:47 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
15:02:49 <yselkowitz> .hello yselkowitz
15:02:51 <zodbot> yselkowitz: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
15:02:51 * mjw frantically reads up on meetbot
15:02:52 <langdon> please say hello :)
15:02:54 <geppetto> .hello james
15:02:54 <zodbot> geppetto: james 'James Antill' <james.antill@redhat.com>
15:03:00 <mjw> .hello mjw
15:03:01 <zodbot> mjw: mjw 'Mark Wielaard' <mark@klomp.org>
15:03:11 <langdon> mjw, https://fedoraproject.org/wiki/Zodbot#Meeting_Functions :)
15:03:28 * langdon has to keep it open to remember what to do
15:04:52 <langdon> more people gonna say hi?
15:05:25 <mjw> I also don't have enough time today, sorry. Have to pick up my kids in 10 minutes. Just wanted to introduce myself. Will read the backlog later.
15:05:25 <langdon> meh.. lets get started :)
15:05:38 <langdon> mjw, cool
15:06:04 <langdon> #agenda governance
15:06:28 <langdon> so.. i took a pass at writing up a governance charter..
15:06:30 <threebean> .hello ralph
15:06:31 <zodbot> threebean: ralph 'Ralph Bean' <rbean@redhat.com>
15:06:31 <langdon> #link https://fedoraproject.org/wiki/Modularity_Working_Group/Governance_Charter
15:06:42 <langdon> #info proposed governance
15:07:15 <bconoboy> .hello blc
15:07:16 <zodbot> bconoboy: blc 'Brendan Conoboy' <blc@redhat.com>
15:07:34 <langdon> i mostly cribbed from server-wg as we discussed.. but i kinda broke it in to a "strategy" and a "dev" .. not so much that it is different people but more because the parts, probably, operate a little differently
15:08:08 <langdon> the "strategy" part are the people who can attend this meeting, talk on the mailing lists, help to groom cards, vote on issues, etc..
15:08:33 <langdon> the "dev" team part (and "dev" == "all the production of stuff: docs, tests, code, etc"
15:08:54 <langdon> uses a scrum/kanban model.. with standups and sprint planning sessions
15:09:14 <langdon> ohh.. i forgot one aspect of the "strategy" part.. attend and comment on demos
15:09:30 <langdon> "dev" team produces/delivers demos of the stuff they worked on in the last sprint
15:09:47 <contyk> .hello psabata
15:09:48 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:10:20 <langdon> so.. comments? basically i am thinking.. please comment here, the talk page, or in the wiki itself.. we send it to the mailing list, then give it a week, then vote on it next week
15:11:20 * langdon fetches coffee for the group..
15:11:26 <threebean> langdon: first glance it looks good here.  the standups and sprint planning seem to have been working well for releng over the past few months.
15:11:30 <langdon> we seem to be less talky today :)
15:12:04 <langdon> threebean, would love to hear some advice (perhaps not here) on how to model those meetings for maximum exposure
15:12:13 <nils> langdon: must be related to feeling chewed up and spit out :)
15:12:22 * nils was not born for meetings
15:12:35 * threebean nods
15:13:24 <langdon> hmmm.. ok.. so a ~1 from threebean.. any other comments?
15:14:02 <geppetto> langdon: One thing I've seen is that the Ceph guys push their video to youtube
15:14:17 <langdon> geppetto, like demo video?
15:14:21 <geppetto> yeh
15:14:54 <geppetto> They call it something weird like a monthly dev. meeting … but it's basically the same thing
15:14:54 <nils> langdon: sounds sound to me, but I'm not sure if I should be voting :)
15:15:28 <langdon> geppetto, was also thinking jitsi which I know threebean is using for web-dev-workshop
15:15:48 <langdon> nils, i am just looking for comments on the governance.. looking for votes next week
15:15:56 <nils> ah
15:16:13 <langdon> ok.. i think i am gonna call it agreed.. feel free to quibble in a sec
15:16:21 <bconoboy> agreed
15:16:27 <nils> that illustrates well what level of quality you can expect from me today ;)
15:16:56 <langdon> #agreed send the proposed governance doc to the ML, allow for edits until next WG mtg, then vote (Apr 14)
15:17:01 <bconoboy> langdon: several of us just dropped out of an unrelated concall so we're reading scrollback
15:17:04 <mjw> I am not sure what there is to comment on governance. You want 6 people to take responsibility for pushing things forward? And then everybody designs and hacks on some stuff that we discuss from time to time?
15:17:46 <langdon> mjw, more .. people hack all the time, show demos of results, the 7 people help set the direction of the hacking :)
15:18:07 <langdon> and we use taiga to make sure people aren't hacking on the same things
15:18:08 * contyk reads the backlog
15:18:30 <langdon> mjw, make sense?
15:18:44 <mjw> langdon, I don't know what taiga is, but ok.
15:18:53 <threebean> https://taiga.fedorainfracloud.org
15:18:59 <threebean> mjw: project tracking, tickets, etc..
15:18:59 <langdon> mjw, ohh sorry.. scrum/kanban tool..
15:19:01 <bconoboy> langdon: how does this governance charter differ from the self nominations?
15:19:07 <bconoboy> IE, what's the relationship?
15:19:26 <langdon> bconoboy, self-noms are who will be filled in to the blank 6 open seats
15:19:37 <bconoboy> but we have more nominations than seats
15:19:46 <mjw> Sorry, that doesn't load for me. But any system to keep track for design and todo items is fine of course.
15:19:56 <mjw> Sorry, that was all time (and unconstructive feedback) I had for today. I'll try to see if I can be more useful at some other time (it is time to pick up the kids now or they won't like daddy too much.)
15:20:30 <langdon> mjw, lol..
15:20:50 <langdon> ok.. im gonna call the topic closed.. unless bconoboy i didn't answer your q sufficiently?
15:21:37 <bconoboy> I'm okay, thanks
15:21:40 <mjw> ok, one more feedback. I nominated myself because that was the only way I saw I could introduce myself. I don't need any "voting rights".
15:21:55 * mjw now really gone
15:21:56 <langdon> mjw, well you might get them anyway :)
15:22:10 <langdon> mjw, we can play it by ear to some extent.. see what happens
15:22:31 <langdon> ok.. switching topics
15:22:39 <langdon> #agenda what & when
15:23:23 <langdon> ok.. so .. in the original charter/goals/whatever for modularity wg .. we proposed that we should have a working prototype by f25..
15:23:31 * langdon digs for quote
15:24:08 <langdon> arggh not where i thought it was
15:25:05 <langdon> also notes one of the tasks we are working on is fixing up docs
15:25:49 <rbergeron> langdon: https://fedoraproject.org/wiki/Modularization#Fedora_Objectives ?
15:25:57 <langdon> rbergeron, yeah.. thats it
15:25:59 <rbergeron> Objectives/Fedora Modularization, Prototype Phase
15:26:00 <rbergeron> Summary: The goal of this phase is to deliver a functional implementation of modular Fedora.
15:26:01 <langdon> #link https://fedoraproject.org/wiki/Objectives/Fedora_Modularization,_Prototype_Phase#Deliverables
15:26:03 <rbergeron> Objective Lead: Langdon White
15:26:07 <rbergeron> Timeframe: F25 release, with demo at conferences in early 2017.
15:26:56 <langdon> so.. what we have started to work on .. is some changes to pungi to allow for a build of something like a module..
15:27:09 <threebean> oh?  cool!
15:27:26 <langdon> basically, we want to hack together a "core module" for things to be based on .. even if "core" is not fully defined..
15:27:42 <langdon> then build some modules on "core" .. to start to show how it works..
15:28:12 <langdon> we also have built some bits and pieces to support a module manager.. both as a dnf plugin and a standalone fm tool
15:28:15 <langdon> all in pagure
15:28:51 <langdon> jkaluza_, link?
15:29:01 <jkaluza_> w8
15:29:08 <langdon> i win
15:29:11 <langdon> #link https://pagure.io/fm-dnf-plugin
15:29:23 <jkaluza_> :)
15:29:39 <langdon> basically.. the idea is.. we aren't sure if this is something managed by dnf or if dnf manages it.. so .. jkaluza_ built it so it works both ways for now
15:30:06 <nils> whynotboth.jpg
15:30:22 <langdon> we also hacked together a bit of a "list of modules" server.. which is probably a bit weird.. cause we would like repos to really support the metadata a module needs.. but chicken/egg ..
15:30:35 <langdon> #link https://pagure.io/fm-metadata-service
15:30:48 <langdon> and we stood up a demo version of the server ..
15:30:56 <contyk> basically the server consumes the metadata from the repos
15:31:01 <langdon> right..
15:31:02 <contyk> ale communicates with the plugin/tool
15:31:35 <langdon> so.. jkaluza_ (right?) also built some copr repos where you can install it from.. or you can get the source directly
15:32:10 <jkaluza_> yes, there's a link to that repo on fm-dnf-plugin pagure page
15:32:15 <langdon> but.. it is really just some test code.. to statr to get some ideas going
15:32:58 <langdon> and we have some problems with "terms" like.. do you "enable", "install", "run" a module? we aren't sure which makes sense
15:33:20 <langdon> ok.. so that is a lot to look through.. but .. it is really just a start..
15:33:32 <langdon> wanted to start making an infrastructure that we can play around with..
15:33:49 <langdon> cause building something from a blank page is tough..
15:33:53 <rbergeron> module in itself is a pretty overloaded / overused term and people carry around their interpretations :)
15:34:03 <langdon> rbergeron, no lie
15:34:10 <langdon> we tried to scope it a bit with:
15:34:23 <nils> let's do agile and come up with a almost but not quite totally unrelated term for it :o)
15:34:31 <langdon> link: https://fedoraproject.org/wiki/Modularization#What_is_a_module_.28esoteric.29.3F
15:34:38 <langdon> and
15:34:41 <nils> no I think "module" is good.
15:34:47 <rbergeron> *nod*
15:34:48 <langdon> link: https://fedoraproject.org/wiki/Modularization#What_is_a_module_.28tactical.29.3F
15:35:06 <langdon> so.. please start poking at things..
15:35:12 <rbergeron> (sorry, i'd interact more but kids / school for the next bit)
15:36:24 <langdon> we have been trying to use http://taiga.fedorainfracloud.org/project/langdon-modularity/ for "what we are working on".. and would really like people to add thoughts/comments/things they would like to pick up
15:36:39 <langdon> but .. we have also been learning taiga... so that's fun
15:36:43 <langdon> #link http://taiga.fedorainfracloud.org/project/langdon-modularity/
15:37:00 <langdon> #info taiga board for the modularity stuff people are working
15:37:29 * langdon should add "abstract for flock" to his list
15:37:47 <threebean> langdon: is there discussion somewhere about how to handle conflicts between modules?
15:38:04 <langdon> threebean, currently hiding from that problem :)
15:38:12 <threebean> acknowledged.  ;)
15:38:36 <threebean> unrelated - at one point we batted around the idea of storing the definition of modules in PDC.  has that come up again in the recent infra discussions?
15:38:45 <langdon> basically.. modules "can't" conflict.. but rpms can... so we need to solve the rpm problem.. either by using something else, like containers, or by "fixing" rpm
15:39:31 <langdon> threebean, i still like the idea of using pdc for module definitions.. but pdc, currently, seems to be more focused on managing a "colleciton of modules" .. aka a product
15:39:36 * langdon digs for pdc link
15:39:51 <langdon> so ... we need to think about how to represent it in pdc
15:39:52 <nils> I was against it from the beginning that the guidelines allowed conflicts between packages
15:40:13 <langdon> contyk has been looking at the "definition of a module" in json..
15:40:22 <contyk> it's constantly changing
15:40:51 <langdon> i think if we get that working through pungi.. then we can figure out .. "use pdc as ui for generating json that pungi can build".. thats what i have been thinkgin
15:40:53 <contyk> also, json is suboptimal for that task
15:41:04 <nettux> boa tarde / bom dia
15:41:34 <langdon> #link https://pdc.fedoraproject.org/
15:41:53 <langdon> threebean, thoughts? you probably know pdc way better than i do
15:42:18 <threebean> I'll need to see what considerations contyk has come across so far.  maybe we can talk after the meeting.
15:42:35 <nils> pdf.fedoraproject.org <-> "to support automation of Red Hat engineering workflows" *raises eyebrow*
15:42:37 <langdon> contyk, link to current stuff?
15:42:43 <contyk> https://pagure.io/fm-metadata
15:43:15 <threebean> nils: https://github.com/product-definition-center/product-definition-center - we just need to patch that label.. ;)
15:43:16 <langdon> nils, well.. like most things in software.. i have a tendency to want to turn it on its head :)
15:43:29 <threebean> contyk, langdon: thanks!
15:43:46 <langdon> currently pdc is actually more about capturing the "output" of a release process.. rather than the input as well.
15:44:01 <langdon> like it is more about "documenting what was built" instead of feeding the build
15:44:49 <threebean> langdon: yes/no.  I ran the idea of storing "what should be built" in PDC as well by the PDC authors and they thought it was a good fit... but that doesn't necessarily mean we should do it.  ;)
15:44:51 <langdon> basically.. at the end of the day.. i see pdc has a bunch of rpms listed.. and lets you draw a mapping of "these rpms are in this thing".. which is kinda like a module.. so.. hey.. let's steal that code
15:45:19 <langdon> threebean, we can just call it mdc :)
15:45:47 <threebean> :p
15:45:56 <nils> threebean: sure, "VENDOR = Fedora"? "Fedora Project"?
15:46:17 <nils> or use something else than the vendor in the doc?
15:46:38 <nils> langdon: haha
15:46:40 <langdon> so.. thats what we have been playing with.. i would like to get a flock preso that has.. here is the infra for module-y stuff.. so that we can all play in the same space..
15:47:51 <threebean> sounds good :)
15:47:54 <langdon> so.. that is the nearest term "what".. a flock preso of "how to get started if i want to work on modules" .. maybe even a workshop
15:48:06 <langdon> #info the nearest term "what".. a flock preso of "how to get started if i want to work on modules" .. maybe even a workshop
15:48:53 <langdon> ok.. more comments, thoughts?
15:49:11 <langdon> #topic open floor
15:49:21 <threebean> here's an idea.. forgive me if I'm derailing.
15:49:36 <threebean> what if instead of storing module definitions in PDC (or mdc..) we take the route of dist-git.
15:49:47 <threebean> we recently introduced namespacing in dist-git (and pkgdb) to support building docker containers.
15:49:53 <contyk> I would like that
15:50:05 <threebean> we're re-purposing those namespaces now to also support storing package-specific taskotron checks (that the package owners can update willy-nilly)
15:50:27 <langdon> threebean, i guess i thought dist-git would store the "output" of pdc? or something? basically, i want there to be some kind of UI for module-creation..
15:50:29 <threebean> we could have https://pkgs.fedoraproject.org/cgit/modules/apache-http.git be the git repo that contains the definition of that module.
15:51:02 <contyk> dist-git could track the json (or whatever) + package list
15:51:07 <threebean> contyk: yeah :)
15:51:24 <threebean> langdon: and UI could be built on the side to do initialization.  but that would be a bolt-on, yeah.
15:52:14 <langdon> well.. at the end of the day.. i think we want dist-git to store the "this is the defintion of what got built" for like traceability / reproducibility.. but how it gets in there doesn't nec. need to be vi ..
15:52:49 <langdon> thats what i was thinking for pdc.. was just the ui.. but no the "official storage".. but i may be phrasing that poorly
15:53:18 <contyk> the ui could be a desktop gui tool too...
15:53:21 <threebean> yeah, pdc doesn't provide much of any UI for nicely creating anything.
15:53:28 <langdon> threebean, lol
15:53:36 <threebean> ..just for looking at existing stuff.
15:53:38 <threebean> ;)
15:53:40 <langdon> contyk, i think you should add mobile ui for the next sprint
15:53:52 * langdon kids
15:54:06 <contyk> langdon: juicessh + vim ;)
15:54:44 <langdon> so.. we still need "something" .. to allow for saying what modules make up "workstation default install" too though.. which might look more like pdc
15:55:04 * threebean nods..
15:55:10 <langdon> well.. any which way.. we are a LONG way off
15:55:33 <langdon> in the near term.. yes to dist-git supporting the storage of a module definition.. similar to it storing a spec file
15:55:37 <threebean> as I've come to learn, I think that currently gets defined in the pungi config file that releng keeps.  pdc keeps what "went into" the last workstation artifact.. but not what "will go into" the next one.
15:55:49 * threebean nods
15:55:57 <langdon> and dist-git storing the "unchangeable" version of "what got built"
15:56:09 * threebean squints
15:56:14 <threebean> I dunno.. I think we might be on different pages.
15:56:45 <langdon> like.. a git commit is known to "never change".. so on the output side we know what went in to the build
15:56:47 <threebean> let's talk about it after the meeting and bring it up again next week.. how's that sound?
15:57:19 <langdon> threebean, or just build it.. then we can fix it if it doesn't work :)
15:57:38 <threebean> :p
15:58:15 <langdon> ok.. anything else? we have 3m .. so it has to be short :)
15:58:53 <langdon> ok.. countdown begins.. 30 sec
15:59:09 <langdon> 15s..
15:59:26 <langdon> #endmeeting