15:00:00 <nils> #startmeeting modularity_wg
15:00:00 <zodbot> Meeting started Tue Jul 12 15:00:00 2016 UTC.  The chair is nils. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:00 <zodbot> The meeting name has been set to 'modularity_wg'
15:00:44 <nils> #meetingname Weekly meeting of Modularity WG
15:00:44 <zodbot> The meeting name has been set to 'weekly_meeting_of_modularity_wg'
15:01:21 <nils> #chairs: dgilmore, jkurik, langdon, sct, tflink
15:01:29 <nils> #chairs: dgilmore, jkurik, langdon, sct, tflink
15:01:57 <nils> #topic Roll Call
15:02:03 <jkurik> .hello jkurik
15:02:03 <nils> .hello nphilipp
15:02:03 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
15:02:06 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
15:02:25 <langdon> .hello  langdon
15:02:26 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com>
15:02:29 <sct> .hello sct
15:02:30 <zodbot> sct: sct 'Stephen Tweedie' <sct@redhat.com>
15:03:31 * threebean is here
15:03:34 <nils> aah
15:03:37 <nils> #chair threebean
15:03:37 <zodbot> Current chairs: nils threebean
15:03:41 <nils> oops
15:03:44 <nils> #chairs: dgilmore, jkurik, langdon, sct, tflink
15:03:47 <threebean> :p
15:03:49 <nils> #chair dgilmore, jkurik, langdon, sct, tflink
15:03:49 <zodbot> Current chairs: dgilmore jkurik langdon nils sct tflink threebean
15:03:51 <lkocman> :-P
15:04:13 <nils> there we go...
15:04:19 <nils> #topic Agenda
15:04:42 <nils> #link Weekly agenda in usual place, http://piratepad.nl/modularity-wg-agendas
15:04:46 <nils> #link Weekly agenda in usual place, http://piratepad.nl/modularity-wg-agendas
15:05:00 <nils> Do I repeat the Agenda here?
15:05:14 <langdon> nils, i usually do as #info
15:05:21 <nils> tnx
15:05:22 <langdon> like #info for each item
15:05:22 <nils> ok
15:05:36 <nils> #info s/modularization/modularity/g
15:05:44 * langdon getting slightly less distracted
15:05:48 <nils> #info What to do about Taskotron and repoclosure/depcheck
15:05:58 <threebean> nils: can you post the link from the agenda too?
15:06:09 <nils> and that's it for the agenda
15:06:20 <nils> threebean: I guess it's better when we get to that topic, or not?
15:06:43 <threebean> sure :)
15:07:00 <nils> andway, that's today's rather short agenda
15:07:07 <geppetto> This is the ticket: http://taiga.fedorainfracloud.org/project/modularity/us/518
15:07:11 * contyk forgot about the meeting :|
15:07:15 <contyk> .hello psabata
15:07:16 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:07:24 <asamalik> .hello asamalik
15:07:24 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
15:07:31 <nils> contyk, asamalik: no worries, we're just past the agenda
15:07:37 * asamalik talked with contyk and also forgot :(
15:07:43 <tflink> .hello tflink
15:07:44 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
15:08:04 <nils> it's on http://piratepad.nl/modularity-wg-agendas also
15:08:07 <contyk> thanks
15:08:19 <nils> #topic s/modularization/modularity/g
15:09:05 <nils> I don't know who put that on the Agenda, what I know is that we've been using both terms in the past and want to go on with "Modularity" from now on.
15:09:25 <langdon> #link http://piratepad.nl/modularity-wg-agendas < modularity wg meeting agenda
15:09:26 <langdon> ha.. nils already had
15:09:28 <langdon> actually langdon just can't read
15:09:30 <langdon> threebean, lets wait for the topic
15:09:33 <langdon> nils, move on to first topic? unless anyone else has agenda items?
15:09:43 <nils> langdon: already did, kinda :)
15:10:12 <nils> langdon: do you know who put the change from modularization to modularity on the Agenda?
15:10:15 <asamalik> I just put the sprint 9 demos to this meeting - I messed it up before and added it into the previous one...
15:10:38 <jkurik> this topic should be imo just FYI, as the decision has already been made, right ?
15:10:47 <contyk> pretty much
15:10:56 <contyk> modularity is shorter and easier to say :)
15:11:06 <sgilson> yes!
15:11:06 <jkurik> yes, it is :)
15:11:10 <contyk> we've already renamed the irc channel, the pagure groups and a number of wiki pages
15:11:17 <contyk> also the youtube channel
15:11:25 <nils> gotcha
15:11:52 <nils> now how to put that in one short simple sentence...
15:12:41 <nils> #info We use "Modularity" to refer to the effort from now on. It's easier to type and pronounce.
15:12:58 <langdon> my irc is REALLY laggy.. i am not sure whats up
15:13:12 <langdon> actually.. lets switch to the other topic.. trying to get the docs guy to join the meeting
15:13:17 <langdon> and we can come back
15:13:21 <nils> #info Wiki pages, IRC and Youtube channels have been renamed to the new name.
15:13:22 <sgilson> langdon: here
15:13:38 * langdon gonna try reconnecting to the internet.. see if that helps
15:13:41 <nils> sgilson: thanks for the changes you did there on the documentation btw
15:13:53 <sgilson> nils: just getting started
15:14:39 <nils> sgilson: in the WG meetings we usually announce us to the bot as ".hello <FAS username>" -- I use ".hello nphilipp" and zodbot will from now on know me (for the duration of meeting)
15:14:52 <haraldh> .hello haraldh
15:14:56 <haraldh> .hello harald
15:14:56 <zodbot> haraldh: Sorry, but you don't exist
15:14:59 <zodbot> haraldh: harald 'Harald Hoyer' <harald@redhat.com>
15:15:10 <nils> sgilson: as haraldh did
15:15:15 <mprahl> .hello mprahl
15:15:16 <zodbot> mprahl: Sorry, but you don't exist
15:15:16 <langdon> ok.. i think i am back
15:15:31 <haraldh> FAS username
15:15:38 <threebean> mprahl: ah, zodbot doesn't like it if you don't yet have a FAS account.  you can create one at https://admin.fedoraproject.org/accounts
15:15:38 <langdon> sgilson, rough plans for next steps?
15:15:43 <sgilson> .hello sgilson
15:15:44 <zodbot> sgilson: sgilson 'Stephen Gilson' <sgilson@redhat.com>
15:15:45 <nils> #chair haraldh
15:15:45 <zodbot> Current chairs: dgilmore haraldh jkurik langdon nils sct tflink threebean
15:16:05 * threebean pats zodbot on the head
15:16:08 <nils> sgilson: and welcome of course :)
15:16:20 <sgilson> next steps: post the FAQ and edit the default page to remove redundant contnet
15:16:34 <sgilson> also, draft an IA and get some reviews
15:16:44 <sgilson> for navigation, categorization
15:16:49 <nils> sgilson: an IA? what's that for a non-docs person?
15:16:58 <sgilson> information architecture
15:17:00 <langdon> sgilson, did anyone ever get back to us about using answers.fp.o for the faq?
15:17:09 <nils> sgilson: tnx
15:17:22 <sgilson> langdon: not sure, I'm still digging out from vacation
15:17:25 <langdon> sorry ask.fp.o
15:17:39 * langdon digs for link
15:17:54 * nils hands sgilson a shovel ;)
15:17:56 <sgilson> yeah, I don't recognize that request
15:18:05 <sgilson> select All > delete?
15:18:11 <nils> haha
15:18:21 <langdon> #link https://ask.fedoraproject.org/en/question/88488/faq-for-modularity/
15:18:27 * sgilson looking
15:18:29 <nils> sgilson: shall I put the above as an action item for you?
15:18:36 <sgilson> sure thing
15:18:50 <langdon> ok.. end topic?
15:19:08 <nils> #action sgilson next steps: post the FAQ and edit the default page to remove redundant content, draft an IA and get some reviews
15:19:13 <nils> sgilson: sounds right?
15:19:20 <sgilson> yep
15:19:26 <langdon> #action sgilson review/follow up on https://ask.fedoraproject.org/en/question/88488/faq-for-modularity/
15:19:26 <nils> cool, next topic
15:19:39 <nils> #topic What to do about Taskotron and repoclosure/depcheck
15:19:44 <jkurik> #link http://taiga.fedorainfracloud.org/project/modularity/us/518
15:19:45 <nils> #link http://taiga.fedorainfracloud.org/project/modularity/us/518
15:19:53 <nils> beat me ;)
15:19:58 <jkurik> sorry :)
15:20:01 <nils> np
15:20:08 <langdon> its a VERY important link :)
15:20:20 <threebean> hey, so can I introduce this one?
15:20:27 <langdon> threebean, i was just gonna suggest you
15:20:33 <nils> langdon: so we might want to post it in triplicate?
15:20:36 <nils> :D
15:20:44 <threebean> the base issue is that we need to do some kind of validation of these module repos once we create them.
15:20:55 <threebean> we were originally thinking that the tool we use to create them should do that validation(!)
15:21:15 <threebean> then we started to separate those out and say, oh, no, maybe the tool that creates them should be separate from the tool that validates them.
15:21:31 <threebean> we were going to write our own thing to do that validation, triggered by message bus, and it would store its result in PDC.
15:21:33 <langdon> +1
15:21:56 <langdon> +1 was for separate not writing our own
15:22:08 <threebean> that's good insofar as it separates the concerns of artifact-production and validation.  but it occurs to us that we already have a message-bus-triggered validation framework for Fedora... taskotron, and also its own results-storage framework, resultsdb.
15:22:46 <threebean> furthermore!  taskotron already has a check called 'depcheck' that does *almost* exactly what we want for 'repoclosure', the thing we started out wanting to do.
15:22:46 <sct> threebean: If we separate them, can we still make sure that a module compose which fails validation doesn't get used as a base for other builds, or pushed to users etc?
15:23:11 <threebean> sct: my thought is that if we force all of our qa into taskotron/resultsdb, then that will be easier.
15:23:15 <sct> ie. it should still be part of the success criteria for the build as far as possible
15:23:24 * threebean nods
15:23:38 <threebean> we already have code in bodhi that *gates* individual rpm updates based on taskotron results.
15:24:03 <threebean> if we wrote our own thing, we would have to expand that gating code to also check somewhere else (pdc?)
15:24:04 <tflink> fwiw, i don't know of a reason why taskotron tasks couldn't report to PDC
15:24:07 <nils> so the success criterion is not "the tree is built" but "... and taskotron tests ran successfully"?
15:24:32 <threebean> nils: I think so, yes.
15:24:46 <threebean> tflink: interesting.  that is a valid point.  we would just need a new PDC directive, right?
15:24:52 <tflink> yep
15:24:59 <threebean> well, that's an option.
15:25:00 <langdon> nils, well.. we need that anyway.. or at least "tests ran successfully" .. we have tried to be loose about "where tests are run" to this point..
15:25:10 <nils> langdon: yes, of course
15:25:21 <geppetto> threebean: also bodhi isn't really the gate for building/rebuilding other modules
15:25:30 <threebean> geppetto: true.
15:25:55 <tflink> the only potential stumbling block for the short term is that we haven't implemented anything to handle secrets that need to be at least somewhat hidden
15:26:08 <threebean> we would need to add resultsdb checks (similar to how bodhi does them) to either the module-build-service or the auto-rebuilder
15:26:08 <langdon> but we need a "source of truth" for a module being 1) built 2) ready for prime time .. is that bodhi? pdc? something else?
15:26:24 <threebean> tflink: I think we're okay without secret-management for this one.
15:26:41 <sgilson> .me back in 5
15:27:04 <contyk> I think it's a combination of sources
15:27:10 * threebean nods
15:27:15 <threebean> and BPO consolidates that info for you.
15:27:31 <contyk> +1
15:28:06 <threebean> any other questions so far?
15:28:46 <langdon> threebean, can you recap the qs and as you feel like are satisified?
15:29:05 <threebean> langdon: I don't understand.  :(
15:29:15 <threebean> can you re-state?
15:29:36 <jkurik> threebean: can you please summarize what is going to be done
15:29:41 <langdon> threebean, you seem to be concluding the topic.. and, i for one, got a little lost.. can you recap what you think was answered?
15:29:46 <threebean> oh, sorry.
15:30:02 <threebean> I was trying to lay out the context first... before proceeding a little further.
15:30:11 * threebean does that now
15:30:29 <threebean> we have this existing check, 'depcheck' in taskotron.  it does a lot of what we wanted our 'repoclosure' task to do.
15:30:45 <threebean> it verifies that dependencies are satisfied and complains if they are not.
15:30:58 <threebean> here's where they differ:
15:31:23 <threebean> 1) depcheck reports its successes and failures *in terms of the individual packages in the repo*
15:31:47 <threebean> 2) we want our repoclosure task to report its successes and failures *in terms of the module*
15:32:24 <threebean> so if it fails, we know that build XXX of module YYY failed.  not that, rpm foo-1.2.3-1.YYY failed.
15:32:42 <nils> threebean: I assume people still can dig further to get info about individual pkgs failing to repoclosure, right?
15:32:51 <nils> (should I mean)
15:33:09 <geppetto> threebean: as nils said, we still kind of want to know why the module failed
15:33:11 <sct> threebean: There's one additional change we'd like: ability to specify external APIs for modules ("exported" rpms), and check that other modules are using only that subset
15:33:13 <threebean> nils: well, that would be up to us on how we adapt this, I think.  they would certainly have access to a log.
15:33:27 <nils> threebean: that should be enough
15:34:36 <threebean> sct: hm.  that's significant enough that it probably warrants its own 'check' in taskotron.
15:34:43 <nils> sct: i.e. that a module doesn't export all packages it carries, but only certain specified ones?
15:34:53 <threebean> sct: important yes, but different.
15:35:10 <sct> nils: Right.  So you can specify internal-only implementation details that can be changed later without affecting the module's official external API
15:35:40 <sct> threebean: Related, but different, yes.
15:35:45 <langdon> sct, and, really, that is part of the "what does it mean to test a module".. personally, the repoclosure part is just a "sign off" it doesn't really tell us much about whether the module "works as expected"
15:36:35 <sct> langdon: Right, I think all of these are just parts of signoff --- that's one reason I'm happy to see this move outside the build, because a lot of qe smoke-testing also fits in the same basic readiness testing
15:36:42 <langdon> in other words, part of normal flow to test for repoclosure, part of "specific module test" to ensure that its api promises are being kept (on both sides of the api)
15:36:54 <nils> sct: just in passing, that has interesting implications if two modules use the same component as an internal detail, but different versions
15:36:56 <threebean> +1
15:37:51 <tflink> taskotron is capable of triggering jobs based on results of other checks - something along the lines of "does this work as expected" kicked off when repclosure/depcheck passes
15:38:14 <threebean> I hadn't realized.. but that is very nice :)
15:38:23 <sct> nils: Agreed, "bundled" dependencies is something we need to put guidelines around
15:38:43 <langdon> tflink, threebean but we just want a message back to the bus, right? because we may have a "set of things" that happen post repoclosure test, right?
15:38:48 * threebean nods
15:38:56 <threebean> langdon: like building subsequent modules, artifacts, etc.
15:39:00 <tflink> it all works through fedmsgs
15:39:05 <langdon> "set of parallel things"
15:39:12 <langdon> tflink, yeah.. thats what i thought
15:39:19 <tflink> the passing result would emit a fedmsg which could trigger any number of things
15:39:31 <langdon> \o/ bus!
15:39:32 <langdon> ;)
15:39:48 <langdon> same on failure i imagine as well
15:39:53 * threebean nods
15:39:53 <tflink> yep
15:40:01 <threebean> the event is "new result"
15:40:55 <threebean> ok - so, as far as modularity work is concerned, I think this can be broken up into quite a few different cards
15:41:03 <threebean> only some of which we need to target for flock.
15:41:42 <langdon> yay? ;)
15:41:58 <threebean> :)
15:42:26 <threebean> 1) we need to evaluate if we're going to adapt depcheck, or replicate it in a module-specific repoclosure task
15:42:47 <langdon> i would definitely argue for "clone & edit"
15:42:56 <threebean> 2) we need to evaluate if we even need to report results to PDC or not (I think not.. but does RTT need them for something there?)
15:42:56 <langdon> or "embrace and extend" ;)
15:43:15 <threebean> 3) if we need to report results to PDC (in addition to resultsdb which we get for free) then we need to write a PDC directive for taskotron (easy*)
15:43:53 <threebean> 4) we need to adapt our build/rebuild tools to query/respond to resultsdb when there are new results stored for a module check.
15:44:20 <langdon> on 2) can't that just be another fedmsg task? like have taskotron work as it does and the update pdc when the msg fires?
15:44:29 <threebean> +1
15:44:30 <geppetto> #1 would be insane to do IMO, although we made want other checks that are outside depcheck
15:44:49 <langdon> geppetto, which choice is insane?
15:44:57 <geppetto> langdon: rewriting it
15:45:00 <nils> 15 minutes left...
15:45:11 <langdon> geppetto, isn't it just a clone?
15:45:21 <tflink> langdon: not sure I understand what you're asking with "another fedmsg task"
15:45:43 <threebean> https://bitbucket.org/fedoraqa/task-depcheck
15:46:14 <geppetto> Ahhh, copy and paste? ... with minor changes? That's not insane then ... although tflink might be less than happy :)
15:46:15 <langdon> tflink, poor wording.. another use for the fedmsg msg.. like when the msg from taskotron "dep check complete" fires, another service says "ooo let me put that in pdc"
15:46:31 <langdon> geppetto, yes.. but "clone" sounds like it is more program-y ;)
15:46:35 <geppetto> :)
15:46:59 <tflink> geppetto: if it's needed, it's needed. it'd be nice to have one thing to maintain, though
15:47:18 <tflink> depcheck isn't exactly a popular thing for folks to want to help with
15:47:35 <threebean> I *suspect* that the only thing that needs changing is the way that depcheck reports results.
15:47:36 <langdon> i haven't looked at the code but isn't this just 'loop over existing depcheck'?
15:47:54 <threebean> it needs to continue to report results the old way.. and it needs to be able to also (when so configured) report results in the way we'd like.
15:48:02 <geppetto> langdon: no, depcheck already loops over all the rps
15:48:27 <geppetto> langdon: What we need is more cascading the failure ... so any rpm failure in the set fails the entire set.
15:48:28 <threebean> a glance at the code here shows that there is a little abstraction around how results get "squashed", so that could be a good place to hack:
15:48:30 <threebean> https://bitbucket.org/fedoraqa/task-depcheck/src/4cd6aaf3e60789dbedde293f04a26e9218570258/depcheck/__init__.py?at=develop&fileviewer=file-view-default#__init__.py-128
15:48:32 <tflink> langdon: that'd be possible but I'd question whether that would be worth it for just depcheck. taskotron was designed with reporting to multiple systems in mind
15:48:43 <langdon> geppetto, ohh yeah.. i see that now... maybe it doesn't even need to be changed.. could this just be a "msg from taskotron for a module means it has different outcome" ..
15:49:50 <langdon> but i suppose it would (potentially) still do a lot of work on testing when it has already actually failed
15:50:05 <nils> 10 minutes to go -- is that enough for you guys (we have one more topic)?
15:50:16 <langdon> nils, what is it?
15:50:17 <nils> (which is just an FYI)
15:50:31 <nils> langdon: YT demos, and open floor obv.
15:50:37 <langdon> gotcha..
15:51:23 <threebean> all good here.
15:51:26 <langdon> threebean, i feel like this is now more "discussion" .. not "decision" .. sounds like "decision" is yes use the taskotron depcheck.. but it may need some modification/cloning
15:51:37 <langdon> threebean, #actions #infos?
15:52:09 <threebean> +1 to geppetto's comment on cascading the failure.
15:52:31 <threebean> geppetto: can you and I sync up to revise the card(s)?
15:52:48 <geppetto> threebean: sure
15:53:02 <threebean> #action geppetto and threebean will sync up to revise the card for this sprint.
15:53:04 <geppetto> I'm free all afternoon
15:53:07 <langdon> woot!
15:53:15 <threebean> geppetto: thanks :)  similar here.  will send a gcal thing!
15:53:18 <langdon> nils, next! before they keep talking!
15:53:22 <langdon> :)
15:53:25 <geppetto> ha
15:53:28 <contyk> :)
15:53:29 <nils> okay :)
15:53:38 <nils> #topic Sprint 9 Demos
15:53:49 <nils> asamalik?
15:54:22 <asamalik> we have created demos for the sprint 9 and they are on our youtube channel
15:54:22 <nils> I guess I can do it as well, it's just an FYI
15:54:28 <nils> asamalik: go ahead
15:54:34 <contyk> nils: be patient ;)
15:54:53 <asamalik> a link to the playlist is in the etherpad
15:54:57 <asamalik> that's it from me
15:55:03 <nils> #link https://www.youtube.com/playlist?list=PLcwHJG45BmAMWP-eLj9WcY90N7kJnUNJD
15:55:05 <asamalik> :-)
15:55:12 <nils> that should be the linke
15:55:15 <nils> *link
15:55:19 <nils> okay
15:55:23 <langdon> asamalik, can you also add the links to the videos on the fp.o/modularity server for people who don't like the yt?
15:55:37 <asamalik> langdon: sure
15:55:42 <langdon> asamalik, thanks
15:55:51 <langdon> just in the epad.. not here
15:56:13 <langdon> ok.. open floor for a few minutes?
15:56:14 <nils> #topic Open Floor
15:56:16 <asamalik> langdon: ook
15:56:23 <nils> any topics for open floor?
15:56:29 <langdon> i have one...
15:56:39 <langdon> come to my talk! at flock! please :)
15:56:50 <contyk> I'll think about it
15:56:59 <langdon> anything anyone would like to see? in particular?
15:57:06 <sgilson> thinking of requesting approval for flock
15:57:25 * langdon notes contyk will be banned from the talk to avoid at least once source of heckling
15:57:47 <nils> He'll send Waldorf and Statler as substitutes :P
15:58:03 <langdon> moar muppets!
15:58:30 <langdon> ok.. seriously folks? I think we are gonna try and demo multi version modules.. some docs.. and maybe a build engine..
15:58:50 <langdon> but if other people have open floor items.. feel free to jump in
15:59:02 <contyk> are we going to have that workshop?
15:59:03 <threebean> :)
15:59:21 <langdon> contyk, ugh.. i owe a follow up to the organizers.. soooo behind
15:59:32 <langdon> but trying, yes.. contyk will be leading it :)
15:59:48 <bconoboy> We still on open floor?
15:59:50 <nils> any other open floor topics?
15:59:54 <langdon> bconoboy, yes
15:59:56 <nils> bconoboy: ^
15:59:58 <bconoboy> I was wondering when everybody is arriving at flock
16:00:19 <langdon> i think i am getting there sunday
16:00:21 <contyk> Monday evening
16:00:23 <asamalik> bconoboy: on monday
16:00:29 <jkurik> Monday evening
16:00:29 <threebean> same here.
16:00:30 <langdon> but i ask tripit about all these things
16:01:02 <bconoboy> do you all want to get together for some modularity group thing on a day that doesn't have an official flock evening event?
16:01:16 <contyk> sure, if there's one
16:01:44 <langdon> yes please..
16:01:58 <langdon> bconoboy, signing up to organize?
16:02:12 <bconoboy> langdon: I might be signing up to pay ;-)
16:02:18 <langdon> bconoboy, lol
16:02:27 <bconoboy> Just want to see if people are up for it and if so when
16:02:38 <langdon> anybody on the team know krakow at all? want to sign up to organize?
16:03:22 <contyk> nope
16:03:34 <bconoboy> let's revisit next week, I'll see if I can find somebody
16:04:01 <langdon> bconoboy, cool.. i am not sure when the official flock party(ies) is ..
16:04:07 <langdon> ok.. close the meeting?
16:04:33 <nils> bconoboy: you'll put that on the agenda for next week?
16:04:38 <bconoboy> nils: y
16:04:41 <nils> ace
16:04:48 <nils> okay, anything else?
16:04:59 <nils> 3
16:05:01 <nils> 2
16:05:04 <nils> 1
16:05:07 <nils> #endmeeting