15:02:41 <sct> #startmeeting Modularity WG weekly meeting
15:02:41 <zodbot> Meeting started Thu May  5 15:02:41 2016 UTC.  The chair is sct. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:41 <zodbot> The meeting name has been set to 'modularity_wg_weekly_meeting'
15:02:48 <contyk> .hello psabata
15:02:49 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:02:52 * threebean 
15:02:56 <sct> #chairs blc, dgilmore, haraldh, cydrobol, tflink,
15:03:02 <sct> .hello sct
15:03:03 <tflink> .hello tflink
15:03:03 <zodbot> sct: sct 'Stephen Tweedie' <sct@redhat.com>
15:03:06 <jkaluza> .hello jkaluza
15:03:06 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
15:03:09 <zodbot> jkaluza: jkaluza 'Jan Kaluža' <jkaluza@redhat.com>
15:03:09 <dgilmore> hola
15:03:32 <sct> Greetings for the week's IRC meeting!  Langdon can't make it right now so I'll be chairing in his absence.
15:03:50 <sct> It may be short, we'll see how the topics go ---
15:04:12 <sct> #link Agenda for this week is at http://piratepad.nl/modularity-wg-agendas
15:04:14 * jkaluza has two things for the end of meeting
15:04:37 <sct> #topic Review package lifecycle diagrams
15:04:56 <threebean> so, on this, I had hoped to have two diagrams done for today..
15:05:01 <sct> First topic is on module lifecycles; threebean, have we got anything we want to dive into on this?
15:05:07 <linuxmodder> .hello linuxmodder
15:05:08 <zodbot> linuxmodder: linuxmodder 'Corey W Sheldon' <sheldon.corey@openmailbox.org>
15:05:10 <threebean> one on the current 'lifecycle of a package update'
15:05:23 <threebean> and another on that same lifecycle in our modular future.
15:05:25 <dgilmore> threebean: autosigner does not really work today
15:05:40 <dgilmore> it si fragile
15:05:41 <threebean> heh, well scratch that ;)
15:05:42 * linuxmodder here mostly to  wrap head around this
15:05:44 <threebean> http://threebean.org/img/modularity/life-of-a-package-update-current.png
15:06:25 <threebean> I'm not sure if the info in that diagram is something well-known to people, or if it will be new information.
15:06:33 <sct> #link Package lifecycle diagram: http://threebean.org/img/modularity/life-of-a-package-update-current.png
15:06:39 <threebean> but we could take questions on it, or comments (like dgilmore's comment about the rawhide autosigner, for instance)
15:07:01 <dgilmore> threebean: you have some inaccuracies over signing
15:07:10 <threebean> for next week, we should have a proposed diagram of the same flow, but with modules involved.  showing modules' own lifecycle, as well as the way package lifecycle may change as a result.
15:07:27 <threebean> dgilmore: oh yeah? fill us in please.
15:07:31 <dgilmore> threebean: and tha workflow for tagging
15:07:41 <dgilmore> threebean: packages are only signed once
15:07:59 <threebean> for updates-testing?
15:08:27 <dgilmore> threebean: and package tags and bugzilla are updated at both the testing and stable phases
15:08:39 <dgilmore> threebean: before going to updates-testing
15:08:58 <threebean> yeah, I couldn't fit those arrows in the diagram.. ;)  it's mentioned in the text there though.
15:10:07 <dgilmore> the rpms are signed manually, sigul line needs to go
15:10:24 <jkaluza> contyk: isn't it similar to what we've been discussing yesterday?
15:10:47 <jkaluza> contyk: Talking about threebean's "for next week, we should have a proposed diagram of the same flow, but with modules involved".
15:11:07 <contyk> contyk: we were mostly talking about build, no the update process
15:11:12 <threebean> dgilmore: right, again, because things are signed before they go into updates-testing (not again for stable), correct?
15:11:14 * contyk is talking to himself
15:11:19 <contyk> jkaluza: ^
15:11:20 <dgilmore> threebean: correct
15:11:33 <threebean> dgilmore: can fix.  thanks!
15:11:56 <jkaluza> contyk: ok :) I just see first half of the image is describing what we've been talking about.
15:12:10 <sct> threebean: OK, so for next week, we'll keep this on the agenda, polish the package lifecycle, and come back with an analogous lifecycle idea for modules?
15:12:11 <tflink> threebean: i don't know if I'm getting to far ahead or if it's relevant to your diagram, but we're going to support running taskotron checks on dist-git commit before much longer
15:12:15 <dgilmore> threebean: we want to sign the repo metadata, but today we can not as it is a manual step at the end of the long push process
15:12:35 <threebean> tflink: that's good to know.
15:13:03 <threebean> sct: yes.  if there are ideas out there in the group about how modules should fit in here, do bring them up in #fedora-modularization so we can incorporate them.
15:13:44 <sct> Definitely.  We might get more feedback once there's an initial strawman diagram too.
15:13:52 * threebean nods
15:13:53 <threebean> hopefully.
15:14:11 <sct> #action threebean to polish and extend diagrams for next week
15:14:38 <sct> Anything else we want to talk about on this topic this week?
15:15:03 <sct> OK, next topic:
15:15:07 <sct> #topic Demos
15:15:37 <sct> cpacheco: Langdon had your name against this topic, can you lead?
15:15:42 <cpacheco> sct: sure
15:16:31 <cpacheco> So, Paul Frields (stickster) is in charge of giving out authorizations to use the official fedora YouTube channel, which is where we plan to upload videos of our demos
15:16:58 <cpacheco> Since the YouTube channel is run by the fedora marketing team, I asked them what they thought about us uploading videos to YouTube
15:17:15 <cpacheco> They don't mind if we upload videos to the main channel or if we want to create our own subchannel
15:17:23 <cpacheco> I don't know if anyone here has preference
15:17:26 <stickster> cpacheco: Welllll... I wouldn't say I'm in charge. I'm able to do it, but Brian Proffitt technically owns these as OSAS guy in charge of social media
15:17:45 <cpacheco> stickster: ah ok. Good to know :)
15:17:46 <stickster> cpacheco: But typically we agree quickly on stuff like this, so it's probably not an issue for me to do so
15:18:02 * cpacheco makes note of that
15:18:07 <sct> Is there any pattern to how existing subgroups are using it already?
15:18:24 <cpacheco> Apparently the channel isn't really used
15:18:37 <stickster> sct: No, and I'm not sure we want to proliferate random technical videos or meetings there
15:18:46 <sct> I expect the content will be pretty deeply technical
15:19:04 <sct> and not what we want somebody to find who's just looking for introductory Fedora stuff
15:19:35 <stickster> If we have videos of interest to the general Fedora community, those are worthwhile to post. I still haven't seen any of the ones being proposed.
15:20:17 <sct> I think it's important that we can produce demos pretty quickly for the stuff being done in sprints
15:20:20 <stickster> At the same time, I don't want to block using YT for wider distribution -- if we can get BKP involved and agree on a way to organize, I'm perfectly satisfied with that
15:20:38 <sct> aimed at showing content to existing technical WG members
15:21:07 <sct> I expect it would take a lot more time and effort to make things accessible to the general community
15:21:16 <cpacheco> Just to clarify too -- not all our demos will be posted on YouTube, as some of them are private
15:21:17 <jkaluza> Do we need official fedora channel for that, if the audience is just people interested in modularity?
15:21:41 <sct> from my experience with sprint demos, they tend to be fairly brief and highly technical
15:21:42 <jkaluza> We could just create our channel for these videos. Sorry if I'm missing something obvious here.
15:21:53 <stickster> jkaluza: It sounds like the content sct is discussing is different from what cpacheco has proposed.
15:22:06 <stickster> jkaluza: We should discuss this with bkp in the Fedora community
15:22:24 <stickster> I'm not smart enough about marketing to know whether we lose value by splintering off the content.
15:22:24 <sct> Possibly, perhaps I'm jumping to conclusions ---
15:22:36 <geppetto> jkaluza: Yeh, that's what Ceph do … although they are bigger :)
15:22:41 <sct> cpacheco: to be clear, are you talking about marketing / introductory demos, or sprint demos here?
15:22:56 <cpacheco> sprint demos
15:23:10 <jkaluza> If we actually find out that some demo can address general Fedora community, I would use the official Fedora channel to repost the demo.
15:23:33 <stickster> We are doing sprints and demos for things like release tooling -- I don't think those get published on the official YouTube channel.
15:24:17 <sct> stickster: I think the idea here is we'd like to be able to do demos with prerecorded video, rather than using a video conferencing system that isn't necessarily open to all of the Fedora community
15:24:19 <stickster> There may be a sub channel function?
15:24:38 <sct> so a youtube subchannel might well serve for that
15:24:52 <cpacheco> stickster, sct: yeah, that's what langdon was thinking -- a subchannel
15:25:13 * stickster is looking at YouTube and doesn't see a function for this.
15:25:26 <stickster> There are "playlists" where you can organize video content, but it still all goes out the same feed
15:25:47 <sct> Right, playlists is how I've seen this done in the past
15:26:04 <contyk> what's the "channels" tab?
15:26:14 <contyk> https://www.youtube.com/channel/UCnIfca4LPFVn8-FjpPVc1ow/channels
15:26:32 <stickster> contyk: those are subscriptions to other channels.
15:26:53 <stickster> Maybe this does argue for a separate channel for modularity, then we could link to it from the main one.
15:27:02 <stickster> That also prevents the "everyone gets the firehose" problem.
15:27:34 <stickster> That appears to be the YouTube community preferred method, too.
15:27:54 <stickster> jzb: ^^ feel free to chime in here, even though this is bkp's area
15:28:01 <sct> +1 for keeping the in-the-weeds content in a separate channel
15:28:17 <contyk> +1
15:28:18 <sct> though I'd be OK with sharing a single such channel for different WGs, with playlists for each
15:29:03 <stickster> sct: Keep in mind, though, if we are not careful about how we proliferate these channels, it will be difficult for individuals to figure out whom to contact to get content included.
15:29:22 <jkaluza> Should that channel be "owned" by Fedora people owning the official Fedora channel, or should we create it and own it?
15:29:35 <sct> Who owns the current channel, and can help us figure the permissions implications here?
15:29:36 <stickster> sct: I would recommend you, langdon, cpacheco work with bkp to establish ownership through him, with co-management duties where involved WG people can upload.
15:29:40 <stickster> sct: ^
15:29:47 <stickster> oops, jkaluza ^
15:30:19 <stickster> I don't recommend we have multiple random (even involved) people across Fedora "own" the channels, but we *could* have those folks *co-manage* so they can access, upload, etc.
15:30:38 <stickster> Having the top-level ownership concentrated on someone who's accountable for social media makes a lot more sense to me.
15:30:45 <stickster> That ensures continuity, as well
15:30:48 * jkaluza agrees
15:30:51 <cpacheco> stickster: i'm fine with that. that makes sense
15:30:58 <stickster> This is part of bkp's job and I'm sure he'd be willing to work with you guys on setup
15:31:55 <cpacheco> so, have we decided if we're going with playlists or separate channel for our demos?
15:32:20 <sct> I think we're going to pursue separate channel, but will talk with bkp to figure out the best way it might be organised before confirming;
15:32:36 <sct> is that a fair summary of the conclusions so far?
15:32:39 <jkaluza> I think we want separate channel created by the "bkp" with modularity-wg to have rights to publish videos to it.
15:32:47 <jkaluza> sct: looks OK to me.
15:32:57 <cpacheco> sct: yep, fair summray
15:33:14 <sct> cpacheco: Want to take the action for setting up a follow-up with bkp, then?
15:33:22 <cpacheco> sct: sure, I can do that
15:33:35 * cpacheco makes note to follow up
15:33:44 <stickster> sct: yep
15:34:03 <stickster> cpacheco: feel free to include me and I'll help however makes sense
15:34:13 <sct> #agreed We will investigate a separate youtube channel for sprint demos to keep the deep technical content separate from the usual Fedora youtube channel
15:34:15 <cpacheco> stickster: sure, i can do that
15:34:41 <sct> #action cpacheco to set up a discussion with bkp to recommend permissions etc for such a channel.
15:35:19 <cpacheco> Would anyone prefer if I do this over email, or is it fine to ask bkp separately over IRC?
15:35:35 <sct> I really don't mind
15:35:36 <cpacheco> don't know if you guys care/want to see the convo
15:35:59 <sct> we can come back in a future irc meeting here to hear the outcome
15:36:13 <sct> just let us know when you are ready to have it back on the agenda.
15:36:27 <cpacheco> sure
15:36:49 <sct> Anyone else want included in that conversation?  I heard stickster, and I expect langdon wants included, anyone else?
15:37:28 <sct> OK, thanks cpacheco!
15:37:40 <sct> #topic whenisgood results
15:38:08 <sct> Langdon had heard from some voting WG members that they can't make this time slot.
15:38:32 <sct> #link Email requesting feedback on a new WG IRC meeting regular timeslot: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UTOCPHITXCRM7JH2ZH7OVIDVWWQULIMI/
15:38:57 <sct> #link WG timeslot poll: http://whenisgood.net/hzd7x2b
15:39:33 <sct> I don't have the current results from that, Langdon was trying to find a sharable r/o link for that;
15:39:55 <sct> but we'd like to encourage WG members, especially voting ones, to get their preferences in!
15:40:24 <sct> Not sure we can talk much more about it here, since by definition we've only got the subgroup that can make the current timeslot on the meeting right now.
15:40:54 <sct> But any comments before we move on?
15:41:30 <sct> OK, on to one of jkaluza's topics:
15:41:42 <sct> #topic Moduarity-wg copr repository
15:42:03 <jkaluza> OK, we are prototyping some tools around modularity project and there is a need for RPM repository for these projects to do night builds and so on.
15:42:42 <jkaluza> I've found out earlier this week that in copr, you can make a group based on FAS group, so I've created one for modularity-wg just to test things: https://copr.fedorainfracloud.org/groups/g/modularity/coprs/
15:43:16 <sct> #link copr group for the modularity-wg FAS group: https://copr.fedorainfracloud.org/groups/g/modularity/coprs/
15:43:21 <sct> Nice
15:43:24 <jkaluza> This has not been discussed with the modularity-wg before, so I'm just want to know your opinion on that and if you think it's acceptable to have this as an official RPM repo for our testing projects.
15:43:46 <sct> What do you mean by "official", here?
15:44:11 <sct> I don't think a copr needs any official stamp of approval for being where we host our builds;
15:44:22 <jkaluza> I mean "official" like the "copr repository associated with the modularity-wg.
15:44:36 <sct> but maybe there are specific expectations around builds that we're going to be deploying on fedora infrastructure?
15:44:51 <jkaluza> Because there can be only one copr group associated with modularity-wg FAS group.
15:45:11 <wloncom> join ##news
15:45:15 <wloncom> oops
15:45:35 <jkaluza> sct: So far I treat the repo as a way how other people can test stuff we are working on.
15:46:05 <jkaluza> sct: And as a way how to show to the world that these are RPMs for projects we are working on.
15:47:06 <sct> And we definitely want such a repo; copr seems ideal; and if we can have a copr group formally associated with the wg, sounds like a natural thing to do
15:47:36 <sct> so +1 for me; I don't know if there are any gotchas we'd want to check on before agreeing but sounds good to me.
15:48:03 <sct> Any comments/concerns?
15:48:14 <jkaluza> OK, I've just had the feeling that this is something which should be agreed by the whole group and not just by me :)
15:48:42 * contyk is fine with it
15:49:08 <sct> Sure.  And with lazy consensus, we can just agree here, make sure we announce on the list, and deal with any objections if/when they arise.
15:49:35 <sct> I'm not hearing any concerns, sounds like #agreed to me...
15:50:06 <tflink> +1 from me as well
15:50:10 <sct> #agreed We will use the copr group linked to the modularity FAS group to host modularity tool builds
15:50:19 <sct> jkaluza: thanks!
15:50:38 <sct> Next...
15:50:52 <sct> #topic Status reporting for the taiga boards
15:50:56 <jkaluza> My second point is just quick note that we have Taiga Status Report available at http://www.fed-mod.org/taiga-report/ . It just shows the stuff from Taiga in more readable form if you want to check the modularity project status quickly.
15:51:23 <sct> #link #link Status reports on the modularity taiga board now available at: http://www.fed-mod.org/taiga-report/
15:52:09 <dgilmore> do we all need to be added to taiga?
15:52:45 <sct> Not to see the report; I think you do to see the individual cards linked off it, though
15:53:05 <contyk> is that so? I thought it was all public
15:53:08 <dgilmore> I know I am not in the modularisation taiga instance
15:53:15 <threebean> I think anyone can see them, but you need to be added to manipulate them.
15:53:29 <sct> Perfect
15:54:55 <sct> jkaluza: Many thanks for this, I'm already finding it useful
15:55:04 <jkaluza> great :)
15:55:07 <sct> jkaluza: Any further plans for it?
15:55:29 <jkaluza> I'm open for suggestions :) So far I consider it done.
15:56:29 <dgilmore> jkaluza: where does the code for it live?
15:56:29 <jkaluza> It depends what others are expecting from that. Feel free to open card in taiga for improvements you want to see there.
15:57:04 <jkaluza> dgilmore: it's part of the https://pagure.io/fm-trello-taiga-sync
15:57:54 <sct> #info Feedback / feature requests for the report welcome, open a card on trello for requests
15:58:10 <dgilmore> jkaluza: okay, I am wondering if we can not use part of it for the release infrastructure tools work, which likely has a lot of natural crossover with this work, but we use taiga also.
15:58:54 <sct> dgilmore: Can you find the right person to put in touch with jkaluza on that?
15:58:55 <jkaluza> dgilmore: lets discuss that after the meeting, ok?
15:59:06 <dgilmore> jkaluza: me and acarter
15:59:13 <dgilmore> jkaluza: sounds good
15:59:31 <sct> #action dgilmore, jkaluza and acarter to follow up on reusing the reports for the release infrastructure board
15:59:42 <dgilmore> sct: I am assuming pull requests in pagure are welcome also
15:59:48 <sct> OK, we're almost out of time and we're out of agenda
16:00:03 <sct> dgilmore: I expect so!
16:00:10 <sct> Any final comments, questions or topics?
16:00:32 <sct> If not... thanks everyone for joining!
16:00:39 <dgilmore> thanks sct
16:00:43 <contyk> thanks
16:00:43 <sct> #endmeeting