15:01:53 <langdon> #startmeeting modularity-wg 15:01:53 <zodbot> Meeting started Thu Apr 28 15:01:53 2016 UTC. The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:53 <zodbot> The meeting name has been set to 'modularity-wg' 15:02:06 <langdon> #agenda roll call 15:02:11 <sct> .hello sct 15:02:12 <zodbot> sct: sct 'Stephen Tweedie' <sct@redhat.com> 15:02:13 <jkurik> .hello jkurik 15:02:14 <langdon> .hello langdon 15:02:15 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com> 15:02:18 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com> 15:02:21 <geppetto> .hello james 15:02:23 <zodbot> geppetto: james 'James Antill' <james.antill@redhat.com> 15:02:27 <contyk> .hello psabata 15:02:28 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com> 15:02:28 <dgilmore> .gday 15:02:29 <jkaluza> .hello jkaluza 15:02:31 <zodbot> jkaluza: jkaluza 'Jan Kaluža' <jkaluza@redhat.com> 15:02:37 <dgilmore> .hello ausil 15:02:38 <zodbot> dgilmore: ausil 'Dennis Gilmore' <dennis@ausil.us> 15:02:47 <haraldh> hi 15:03:14 <bconoboy> .hello blc 15:03:15 <zodbot> bconoboy: blc 'Brendan Conoboy' <blc@redhat.com> 15:03:18 <maxamillion> .hello maxamillion 15:03:21 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com> 15:03:40 <haraldh> .hello harald 15:03:40 <zodbot> haraldh: harald 'Harald Hoyer' <harald@redhat.com> 15:03:41 <bconoboy> langdon: remember to #chair some people 15:03:41 <tflink> .hello tflink 15:03:43 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com> 15:03:47 <imcleod> .hellomynameis imcleod 15:03:48 <zodbot> imcleod: imcleod 'Ian McLeod' <imcleod@redhat.com> 15:04:00 <langdon> bconoboy, yeah.. planned to do that post naming the voters :) 15:04:04 <maxamillion> imcleod: I did not know that was a bot command :) 15:04:53 * langdon waits til h:05 to move to next 15:05:15 * langdon also badly assumed no one was in a 30m off tz but tried :) 15:05:33 <langdon> ok.. moving on 15:05:38 <langdon> #agenda agenda 15:06:01 <langdon> mild house keeping.. i started an etherpad with agendas.. not sure if it should go somewhere else 15:06:19 <maxamillion> where's the etherpad? 15:06:22 <langdon> #link http://piratepad.nl/modularity-wg-agendas < meeting agendas now live here 15:06:24 <sct> langdon: No strong preference, as long as we don't store notes in it 15:06:33 * langdon notes maxamillion could deal with my slow typing :) 15:06:57 * maxamillion throws a shoe at langdon 15:06:58 <langdon> so c/p to here? or just leave it as a pointer? 15:07:04 <sct> langdon: agree wiki would be better for long term storage; I don't mind where we stick transient agenda stuff. 15:07:12 <langdon> sct, ack.. 15:07:26 <contyk> +1 for the wiki 15:07:46 <langdon> contyk, careful. you will be volunteered.. i find wiki "challenging" 15:07:54 <langdon> ok.. lets start for real.. 15:07:55 <contyk> I don't mind :) 15:07:57 <sct> I assume we link the meetbot minutes into the wiki anyway? That way we'll have a record there regardless. 15:08:06 <dgilmore> etherpad for agenda is fine, if we run the meeting right with zodbot we get good minutes 15:08:10 <langdon> #agenda announcement of voting members 15:08:26 * langdon notes dgilmore is asking a lot from me 15:08:36 <langdon> so.. i hope everyone is here.. 15:08:53 <dgilmore> langdon: :D you will be fine 15:08:57 <langdon> i tried to pick people based on a wide range of "bias" (can't think of a better word right now).. 15:09:13 <langdon> so.. here is the list.. which i did not prepare before hand.. so give me a sec ... 15:10:35 <langdon> Mike DePaulo, Chaoyi Zha, Harald Hoyer, Tim Flink, Stephen Tweedie, Dennis Gilmore 15:10:36 <langdon> and me 15:11:10 <langdon> so... #chair coming up 15:11:47 <langdon> #chair mikedep333 cydrobolt harald tflink sct dgilmore 15:11:47 <zodbot> Current chairs: cydrobolt dgilmore harald langdon mikedep333 sct tflink 15:11:52 <langdon> #chair mikedep333 cydrobolt harald tflink sct ausil 15:11:52 <zodbot> Current chairs: ausil cydrobolt dgilmore harald langdon mikedep333 sct tflink 15:12:11 <langdon> ok.. everyone down with that? everyone here? 15:12:29 <dgilmore> o/ 15:12:39 * haraldh takes a seat... 15:12:48 <langdon> #chair haraldh 15:12:48 <zodbot> Current chairs: ausil cydrobolt dgilmore harald haraldh langdon mikedep333 sct tflink 15:13:05 * langdon notes c/p from wiki != to irc nicks :/ 15:13:13 <langdon> ok.. 15:13:19 <sct> langdon: That would be too easy. 15:13:21 <haraldh> sorry, harald was already taken :) 15:13:22 <langdon> moving on.. unless someone else has a comment? 15:13:54 <langdon> #action langdon to update wiki with names and lock? the noms page 15:14:28 <langdon> #info new modularity wg voting members mikedep333 cydrobolt harald tflink sct ausil 15:14:42 <langdon> ok.. next agenda topic 15:14:57 <langdon> #agenda review metadata proposal from contyk & new cards from sct 15:15:02 <langdon> #chair contyk 15:15:02 <zodbot> Current chairs: ausil contyk cydrobolt dgilmore harald haraldh langdon mikedep333 sct tflink 15:15:14 <sct> Are we not doing "discuss meeting time"? 15:15:15 <langdon> ok.. sct.. take it away? or do you want some intro? 15:15:19 <langdon> sct, oops 15:15:23 <contyk> :] 15:15:26 <langdon> #agenda meeting time 15:15:41 <langdon> ok... so.. obviously, i like this time.. but am open to suggestions :) 15:15:43 <tflink> what does #agenda do? 15:15:46 <sct> wfm too 15:15:51 <contyk> +1 15:16:00 <langdon> arggh did i screw up zodbot again 15:16:08 <tflink> did you mean #topic ? 15:16:10 <dgilmore> #topic meeting time 15:16:12 <langdon> yes yes i did 15:16:22 <tflink> this time works for me, as well 15:16:28 * maxamillion throws another shoe at langdon 15:16:43 * langdon is starting to have quite the collection of shoes 15:16:50 <dgilmore> this time is fine 15:16:58 * langdon also will be adding #topic to the agenda items so he stops forgetting 15:17:02 <haraldh> +1 for this time 15:17:06 <tflink> sounds like a good opportunity for a side-business - used shoe store :) 15:17:12 <maxamillion> this time works for me also, but I'm more of a chicken in this (re: chicken/pig breakfast scenario) so I'm not sure it matters 15:17:25 <langdon> mikedep333, cydrobolt haven't seen you .hello .. hopefully this time works .. 15:17:29 <maxamillion> tflink: :) 15:18:00 <dgilmore> maxamillion: i'll take pig and chicken for breaky 15:18:15 <langdon> #info langdon messed up zodbot again.. look for #agenda before here to see the topic breaks 15:18:49 <langdon> ok.. seems like the ayes have it.. we can always change it later if need be 15:19:13 <langdon> #info thursdays at 15h utc in #fedora-meeting is the official modularity-wg meeting slot 15:19:32 <langdon> #undo 15:19:32 <zodbot> Removing item from minutes: INFO by langdon at 15:19:13 : thursdays at 15h utc in #fedora-meeting is the official modularity-wg meeting slot 15:19:37 <langdon> #agreed thursdays at 15h utc in #fedora-meeting is the official modularity-wg meeting slot 15:19:46 <langdon> ok.. now move on? 15:19:51 <sct> yep 15:19:56 <dgilmore> si 15:20:06 <sct> OK, I'll take this one... 15:20:09 <langdon> #topic review metadata proposal from contyk & new cards from sct 15:20:22 * langdon was wondering about the lack of zodbot feedback 15:20:28 <langdon> ok.. sct? 15:20:36 <sct> So, we now have a metadata format for defining modules 15:20:43 <sct> I'm not sure how easy this will be to change over time 15:20:59 <contyk> should be easy 15:21:09 <contyk> but of course it depends on the tools that use it 15:21:11 <sct> but it's worth anticipating a few things we likely need up-front so we're not constantly breaking tools or data compatibility around it 15:21:14 <dgilmore> sct: will it work for non rpm content? 15:21:17 <sct> yeah 15:21:23 <contyk> dgilmore: it will 15:21:49 <sct> dgilmore: In principle, afaik 15:21:59 <haraldh> link? 15:22:15 <contyk> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6TPL3F6RRHU6FTSN4K2TVV33W3J2463V/ the metadata proposal thread on devel@ 15:22:21 <sct> There was a brief discussion on fedora-devel, and I've done cards for three additional requirements --- 15:22:25 <dgilmore> I could see debian using it, or having modules with npm, rubygems, etc 15:23:12 <maxamillion> dgilmore: has there been talk of trying to coordinate with debian on the metadata format? 15:23:15 <sct> dgilmore: Yeah. There are a _lot_ of open questions around things like how to do updates, security reviews, system manifests for non-rpm content etc 15:23:16 <contyk> note the current proposal is already outdated as we plan to add a few more fields here and there 15:23:22 <sct> but in principle it's something we can work towards. 15:23:38 <sct> Anyway, proposals are 15:23:52 <sct> #link http://taiga.fedorainfracloud.org/project/modularity/us/186?kanban-status=480 --- Define a module's external API 15:24:12 <sct> #link http://taiga.fedorainfracloud.org/project/modularity/us/187?kanban-status=480 --- Define a module's internal components 15:24:27 <sct> #link http://taiga.fedorainfracloud.org/project/modularity/us/188?kanban-status=480 --- Add component history to module metadata 15:24:36 * sct cuts-and-pastes furiously 15:24:53 <sct> None of this is a short-term blocker for anything we're doing afaik 15:25:14 <contyk> I agree 15:25:19 <sct> but it all comes out of things we've seen in fedora over the long term 15:25:40 <haraldh> one thing... "requires:" ... values are the minimum required versions 15:25:48 <sct> mattdm had a really good writeup recently (don't have the link to hand) of how we lose track of why packages get added to the distro 15:25:55 <contyk> haraldh: that's one of the things that might (and most likely will) change 15:26:01 <haraldh> ok 15:26:01 <sct> when somebody wants to add an app and ends up packaging a few random dependencies for that app 15:26:10 <sct> but has no investment in maintaining those dependencies 15:26:12 <dgilmore> sct: most of why we never track 15:26:17 <sct> right 15:26:20 <sct> so 15:26:29 <sct> it's too late to refit that "why is this here" stuff into the distro as a hole 15:26:45 <sct> but I'd *really* like to start out maintaining this sort of information for "why is this thing in this module" 15:27:10 <sct> so we don't end up with the same maintainability questions for modules in the long term. 15:28:18 <sct> Also, I'd like the tools to be able to alert us if dependencies grow unexpectedly, so we've got some way of avoiding unplanned sprawl of minimal installs over time 15:28:50 <langdon> sct, well.. "change at all" right? like i think we want to see modules changing over time ... either larger or smaller 15:28:56 <contyk> it's something our release tools / autoqa could handle, I hope 15:29:02 <langdon> although i suspect it will be "larger" most of the time 15:29:07 <sct> langdon: Change is OK, as long as the tools don't automatically change it for us 15:29:19 <sct> langdon: all I'd like is a manual decision. Which means spotting when dependencies grow. 15:29:29 <sct> That *could* be done by defining expected dependencies explicitly 15:29:32 <sct> and doing repoclosure 15:29:37 <langdon> sct, i guess i was imaging something like insim with alerting.. like monitoring change of modules over time and the distro as a whole 15:29:41 <sct> and failing a module build until repoclosure passes 15:29:57 <sct> or it could be done with something line insim as you say --- do a test after module build. 15:30:03 <langdon> sct, ohh yes.. i see.. i think there is value to the info eithe rway just for edification 15:30:21 <sct> The reason I prefer the manual decision is that it also means we get to record *why* the dependency was added 15:30:28 <maxamillion> langdon: insim? 15:30:34 * langdon digs for link 15:30:41 <sct> so in years to come, we can look and understand why random-python-library-X is in module-Y 15:30:45 <tflink> would there be enough value in adding something along the lines of rpm changelog to the metadata? 15:30:47 <dgilmore> sct: we can get it automatically also 15:30:49 <sct> and we can determine if it's still needed. 15:30:54 <tflink> as a means of tracking why things changed and when 15:30:56 <maxamillion> sct: +1 - that'd be amazing 15:31:02 <langdon> #link http://insim.fedorainfracloud.org/insim/ 15:31:05 <contyk> tflink: please, no 15:31:17 <sct> dgilmore: Right, if we automate the dependency fulfilling then we'd need to automate filling in the why-is-is-here too. 15:31:18 <langdon> #link https://fedoraproject.org/wiki/Insim 15:31:39 <maxamillion> langdon: oh, that's new :) 15:31:55 <langdon> maxamillion, yeah.. very cool... same people did koschei apparently 15:31:56 <sct> tflink: We could, it seems like it would be relatively easy to automate if we had a need for it 15:32:01 <maxamillion> langdon: swank 15:32:05 <dgilmore> sct: indeed, and we suck at manual. 15:32:23 <sct> tflink: but module builds are currently really quick with lubos's stripped-down pungi, and I'd want to avoid excessive processing that slows that down much., 15:32:33 <sct> dgilmore: Yeah. The tools will help us either way here 15:32:33 <langdon> contyk why "no"? like that changelog is useful.. i suspect? or do you mean provide it a different way 15:32:41 <tflink> sct: yeah, just was wondering about explicit in-file vs. relying on git commit messages etc. 15:32:48 <contyk> langdon: changelogs are definitely useful but we could easily keep them in git 15:32:58 <sct> either telling us when the manual step is needed, or actually doing the whole thing automatically 15:33:43 <contyk> most rpm changelogs are the same as the package git changelogs; you're just duplicating the information 15:33:46 <sct> Also, defining the external ABI explicitly lets us do stuff like 15:34:01 <sct> do ABI checking via libabigail etc 15:34:17 <sct> and making sure that cross-module dependencies only use external ABIs 15:34:30 <contyk> tflink: we could generate changelogs from git and put them in the repo / image / other deliverables 15:34:50 <sct> none of which we're doing right now, but it sounds useful later on and we can only do it if we maintain the information from the outset. 15:34:55 <tflink> sct: can't we do ABI checking without defining the external ABI explicitly? 15:35:11 <sct> tflink: We need to define which packages represent the ABI 15:35:20 <tflink> contyk: that make sense. it assumes that the git commit log will be useful but then again, so would a changelog 15:35:35 <sct> tflink: eg. I might want PAM to be the official API for authentication stuff 15:35:35 <tflink> sct: ok, I'm thinking about checking ABI on a per-package level 15:35:41 <langdon> so.. +1 for not using changelogs to track info.. but .. i think we need to support an easy "here is what is new in the module" coming straight from the app itself (e.g. changelog).. without manual intervention unless someone wants to add color for a particular module 15:35:53 <sct> and cracklib to be an internal detail that I can swap out later if I need to 15:36:29 <sct> obviously we need both parts in the module for PAM to work, but I can still say that external users should not talk to the internals directly 15:36:47 <sct> And none of this should make our work harder --- 15:36:56 * tflink is thinking of a different problem - has been working on detecting per-package ABI breakage which is not quite the same thing 15:37:01 <langdon> module-abi: in the near term, we can fail to the abi of the rpms in the module, but we need to be explicitly *not* exposing some rpms/binaries as soon as the module-authors realize how useful it is 15:37:10 <sct> if there does turn out to be a need to use cracklib directly, we can ask for it to be made externally visible 15:37:21 <sct> we just shouldn't take for granted that the maintainer intends for that. 15:38:11 <langdon> and.. it is useful to module-authors to be notified when their internal rpms break abi, right? so something we still would like .. just not *between* modules 15:38:40 <sct> So I guess the questions are, is the rational/request here clear, and do we want to maintain this metadata from the start? We can work out details later as long as we have places to record this sort of thing in the module metadata format. 15:38:40 <langdon> #info fyi, the wiki page of voting members has been update 15:38:44 <contyk> you could use this information to trigger automatic rebuilds of dependent modules 15:38:56 <sct> contyk: Yes, we'd absolutely want to be able to do that. 15:39:00 <langdon> contyk, which information? 15:39:04 <contyk> langdon: ABI changes 15:39:24 <langdon> contyk, ohh definitely.. and which modules need to be triggered instead of mass-rebuilds 15:39:50 <langdon> we want to start a thread on "how can we limit the testing matrix and still be confident of our testing" which is related 15:39:54 <sct> Yes. And avoiding mass-rebuilds when an internal-only package changes, because we know that that package can't be in use by other modules. 15:40:49 <sct> contyk: Anything else from this that you'd like to discuss while we're on the topic? We've used a bunch of time on it, and I don't want to swamp the whole meeting 15:41:02 <dgilmore> sct: we can avoid mass rebuilds by tracking what uses what ABI 15:41:15 <contyk> I'd just add that we're currently investigating how module dependencies should be expressed and handled 15:41:18 <dgilmore> regardless of modules 15:41:40 <sct> dgilmore: Yes. And this goes beyond just modules-as-repositories --- 15:41:40 <contyk> we're also thining about how to build modules and the packages they contain -- I'll send a mail to devel@ with some ideas I have later 15:42:02 <sct> dgilmore: we'd want incremental rebuilds on-demand of higher-level artifacts too, like docker images, anaconda isos, qcow images etc etc etc 15:42:20 <dgilmore> sct: sure 15:42:23 <langdon> ok.. contyk sct any #action / #info you would like to add? 15:42:30 <sct> dgilmore: modules are a part of breaking down the monolithic compose into small, layered builds, they certainly aren't the whole story. 15:42:30 <langdon> or anyone else? 15:42:49 <contyk> hmm 15:42:57 <sct> We can also continue comments/discussion in comments in the cards, or on-list 15:43:01 * langdon notes contyk seemed to imply an #action above ;) 15:43:37 <contyk> #action contyk will send a module build proposal to devel@ for discussion 15:43:44 <langdon> sct, can you send a note to the thread contyk started saying "that" (ie. please see cards x,y,z ro theses logs) ? 15:43:59 <sct> langdon: Good idea 15:44:11 <langdon> then i propose we move on.. 15:44:11 <sct> #action sct to reference metadata cards on the fedora-devel thread 15:44:25 <langdon> i have a couple other things i would like to see here today 15:44:33 <langdon> anyone else? 60s 15:45:05 * langdon notes clocks are slow when watching them 15:45:28 <langdon> #topic open bzs 15:45:50 <langdon> ok.. so we have a couple bzs that need some attention.. 1-2 in dnf and 1 in anaconda 15:46:17 <langdon> geppetto, can you #link the anaconda ones? worth raising here? or do you think enough progress is being made? 15:46:33 * langdon notes lkocman is not here who raised the dnf ones.. 15:47:10 <geppetto> I can link it … but it's been seen by a bunch of ppl, so I think it's fine 15:47:22 <geppetto> #link https://bugzilla.redhat.com/show_bug.cgi?id=1331100 15:47:46 <langdon> geppetto, ok.. we will move on.. suffice to say.. we need anaconda to honor recommends.. which is really more of an RFE than a bug 15:47:55 <langdon> #info we need anaconda to honor recommends.. which is really more of an RFE than a bug 15:48:12 <langdon> for dnf we need dep resolution change.. blanking though.. 15:48:13 <langdon> help? 15:48:56 <geppetto> IIRC it was yum => dnf compat. stuff … and I thought lkockman was working around it 15:48:56 <contyk> the repo priorities? 15:49:00 <geppetto> Yeh, that 15:49:00 <langdon> ok.. im gonna punt.. the dnf team is aware and committing to help.. but i am totally blanking on the details.. 15:49:18 <langdon> and.. i got some help :) 15:49:22 <langdon> but lag.. 15:49:32 <langdon> that is it.. 15:49:53 <langdon> #info need help in dnf about prioritization of repos for updates. dnf team taking a look already 15:50:12 <langdon> ok.. switching topics.. 15:50:18 <langdon> #topic status updates 15:50:40 <langdon> anyone want to provide a #info of what they are up to now? what they plan to demo by next week? 15:51:08 <langdon> i know a number of people are on holiday today 15:51:30 <contyk> we have plenty of spike cards 15:51:33 <geppetto> #info Working on the anaconda/dnf patches to remove weak deps. 15:51:47 <langdon> #info jkaluza to demo status reporting to give a roll up view of taiga http://taiga.fedorainfracloud.org/project/modularity/us/172?kanban-status=472 15:52:01 <sct> langdon: Main one for me is just documentation, writing up what a modular build process could look like 15:52:18 <langdon> sct, do you have a #link which people could follow? 15:52:20 <langdon> or not yet? 15:52:38 <langdon> sct, or maybe a follow up email when a draft is out? 15:52:42 <sct> partly the stuff lkocman has been working on to break down the compose, partly the need to still have the concept of stacks/releases between modules 15:52:51 <sct> Yeah, I'll definitely send it out 15:53:14 <langdon> sct, can i #action an email before next wg meeting? 15:53:38 <sct> Sure: 15:53:51 <sct> #action sct to complete documentation for http://taiga.fedorainfracloud.org/project/modularity/us/183?kanban-status=477 and email to the list 15:53:57 <langdon> cool 15:54:07 <langdon> ok.. next topic? unless anyone has anything to add? 15:54:28 <langdon> #topic inserting item: coverage for next week 15:54:54 <langdon> i meant to add this to the agenda.. i can't make the meeting next week.. kid school meeting.. can someone(s) cover? 15:55:15 <sct> langdon: Sure, let's just plan on discussing agenda beforehand 15:55:22 <langdon> cool.. thanks 15:55:29 <langdon> ok.. last topic.. 15:55:35 <langdon> #topic future outreach 15:55:44 <langdon> this could also be called "open floor".. 15:56:07 <langdon> i did want to make sure we follow up with commops to see if they need anything.. decause, you around? 15:56:24 <langdon> but anyone else have any comments/concerns? 15:56:59 <langdon> also, we will have our first recorded demo avail by the next wg (i hope) 15:57:12 <sct> langdon: I think the modularity stuff is incredibly useful 15:57:22 <sct> langdon: but much of it is pretty abstract right now; 15:57:29 <maxamillion> langdon: swank, I'm a sucker for a good demo ;) 15:57:47 <sct> langdon: building a few examples may make outreach a lot easier. 15:57:53 <contyk> who said it's going to be good? 15:58:01 <sct> heh 15:58:04 <langdon> contyk, me! 15:58:31 * jflory7 is around 15:58:39 <langdon> i decided we should stop futzing around with tech for demos and just pre-record them.. then make them avail.. and have people ask qs on the ML... 15:58:56 <langdon> jflory7, y'all need anything re: outreach/onboarding support? 15:59:28 <langdon> someone we should invite to the meetings for "indoctrination"?!?!? bwhahahha 15:59:45 <jflory7> langdon: decause and I were planning on devoting a solid hour or two to catching up on some ticket work, including working on the on-boarding process for Modularity. One thing that would be nice to have would be a formal announcement about the presence of the Modularity WG on the CommBlog. 15:59:54 <jflory7> We could push that out and then promote it across the channels 16:00:12 * langdon notes that sounds like more writing ;( 16:00:13 <jflory7> We identified three things we want to do ASAP for helping out the Modularity WG 16:00:28 <jflory7> (1) Someone can review the contents of their on-boarding wiki page and pass feedback about them in the ticket, as compared to other on-boarding methods in Fedora 16:00:28 <jflory7> (2) Putting together a badge proposal for membership in the Modularity WG (in the form of a ticket on the fedora-badges Trac) 16:00:31 <langdon> sure.. so.. i can write that.. i have another "why modularity" blog post to go soon too 16:00:33 <jflory7> ^^ things CommOps will help with 16:00:39 <jflory7> (3) A Community Blog article announcing the presence of the Modularity WG, what they are, what they do, how to get involved (penned by one of the WG members) 16:01:02 <jflory7> It doesn't have to be super long or detailed, but there is a good example of the Mono SIG's post that was well-received 16:01:04 * jflory7 digs for a link 16:01:52 <langdon> jflory7, in (1) who is the someone? one of us? or your team? 16:01:54 <jflory7> Oh, it was actually their 2015 Year in Review. But it was also a really good chance for them to get some exposure and they had a few interested people pop in after the post was published. https://communityblog.fedoraproject.org/mono-sig-year-review/ 16:02:01 <jflory7> langdon: Yeah, someone from CommOps. 16:02:30 <jflory7> decause and I are going to try to tackle (1) and (2) tonight and/or tomorrow. 16:02:36 <langdon> jflory7, on (2) mattdm has volunteered to provide a lego image.. but he doesn't know it yet :) 16:02:46 <jflory7> :) 16:03:15 <langdon> ok.. anyone want some or all of jflory7 (3)? or should i write it? and/or write it and ask for edits? 16:03:41 <jflory7> CommOps can *definitely* help with the editing part too. 16:04:12 <langdon> by "edits" i really meant "color" etc.. your edits have always been good re: actual content editing 16:04:50 <langdon> ok.. we are over time.. so unless someone wants to volunteer for (3) on the ML.. i will take it 16:05:15 <langdon> #action langdon to write "(3) A Community Blog article announcing the presence of the Modularity WG, what they are, what they do, how to get involved (penned by one of the WG members)" via jflory7 16:05:21 <jflory7> langdon++ 16:05:31 * dgilmore has to run to another meeting 16:05:45 * langdon waves to dgilmore 16:06:27 * haraldh has to leave also.. sorry 16:06:28 <langdon> #info jflory7 & decause to work on: " Someone can review the contents of their on-boarding wiki page and pass feedback about them in the ticket, as compared to other on-boarding methods in Fedora" and "Putting together a badge proposal for membership in the Modularity WG (in the form of a ticket on the fedora-badges Trac)" soon.. 16:06:39 <langdon> just wanted to gt that last #info in 16:06:47 <decause> .hello decuase 16:06:50 <zodbot> decause: Sorry, but you don't exist 16:06:50 <jflory7> Sure thing. :) 16:06:51 <decause> .hello decause 16:06:52 <langdon> closing meeting in 2m unless someone has something else? 16:06:53 <zodbot> decause: decause 'Remy DeCausemaker' <decause@redhat.com> 16:07:25 <decause> thanks all, happy to help :) 16:07:33 * langdon belatedly waves at haraldh 16:07:55 <langdon> meh.. i don't have the patience for 2m.. 16:07:59 <langdon> anyone else? 16:08:14 <langdon> ok.. later y'all.. 16:08:23 <langdon> that was 1:30 anyway :) 16:08:27 <langdon> #endmeeting