15:01:21 <langdon> #startmeeting modularity
15:01:21 <zodbot> Meeting started Tue Nov 12 15:01:21 2019 UTC.
15:01:21 <zodbot> This meeting is logged and archived in a public location.
15:01:21 <zodbot> The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:21 <zodbot> The meeting name has been set to 'modularity'
15:01:27 <langdon> #meetingtopic Weekly'ish Meeting of the Modularity Team
15:01:29 <sgallagh> .hello2
15:01:30 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:37 <langdon> #topic roll call
15:01:44 <sgallagh> .hello2
15:01:45 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:02:08 <langdon> do we have anyone else here? i know contyk is afk
15:02:19 <asamalik> .hello2
15:02:19 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
15:02:33 <langdon> HELLO adam!
15:02:42 <asamalik> HELLO langdon!
15:02:49 <langdon> :)
15:02:50 <sgallagh> NO CARRIER
15:02:58 <langdon> ha
15:02:59 <asamalik> hello STEPHEN?
15:03:03 <langdon> ok...
15:03:06 <langdon> #topic agenda
15:03:11 <langdon> sgallagh: ^^
15:03:41 <sgallagh> #info Agenda Item: FESCo's Ursa Prime Decision
15:04:20 <langdon> sgallagh: anything else?
15:04:23 <langdon> anybody ellse?
15:04:39 <sgallagh> We could theoretically rehash the upgrade-path issues, but I'm not sure anything new will present itself
15:04:54 <sgallagh> I think that's a conversation we need to have with DNF and UX in the same room/call
15:05:03 <langdon> sgallagh: maybe a recap would be good... i am not sure it has been discussed here before
15:05:17 <langdon> #info Agenda Item: upgrade path issue recap
15:05:30 <langdon> #info Agenda Item: open floor
15:05:34 <langdon> ok.. let's roll
15:05:35 <sgallagh> hold up
15:05:40 <langdon> ok
15:05:50 <sgallagh> I'm not chaired, so my #info probably didn't get recorded
15:06:20 <langdon> oop
15:06:22 <langdon> s
15:06:26 <langdon> #chair sgallagh asamalik
15:06:26 <zodbot> Current chairs: asamalik langdon sgallagh
15:06:34 <sgallagh> #info Agenda Item: FESCo's Ursa Prime Decision
15:06:37 <sgallagh> thanks
15:06:44 <langdon> and i oop
15:06:54 <langdon> #vsco ftw
15:07:04 <sgallagh> Better an oop than an oom?
15:07:10 <langdon> lol
15:07:21 <langdon> #topic FESCo's Ursa Prime Decision
15:07:44 <sgallagh> Yesterday, FESCo had a long (and at times, heated) discussion about the future of Modularity.
15:08:28 <sgallagh> Hmm, I was going to paste the link to the minutes, but meetbot appears to be throwing 500 errors
15:08:57 <langdon> sgallagh: ill find it.. keep going
15:09:26 <sgallagh> Ultimately, we were able to force a vote on Ursa Prime.
15:09:32 <asamalik> https://meetbot.fedoraproject.org/fedora-meeting-1/2019-11-11/fesco.2019-11-11-15.00.log.html
15:09:53 <langdon> asamalik: faster than me! but #link?
15:09:54 <sgallagh> The short version is that we have been granted limited permission to deploy it to production.
15:10:05 * asamalik had it open already
15:10:09 <asamalik> oops!
15:10:11 <asamalik> #link https://meetbot.fedoraproject.org/fedora-meeting-1/2019-11-11/fesco.2019-11-11-15.00.log.html
15:10:11 <sgallagh> asamalik++
15:10:11 <zodbot> sgallagh: Karma for asamalik changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:10:18 <asamalik> cookies!!
15:10:53 <sgallagh> I successfully argued that we need a real-world environment to adequately test Ursa Prime's suitability.
15:11:13 <asamalik> cool
15:11:22 <langdon> sgallagh: so... will that be enough to prove its value? how can we make sure it is /was considered the "right" decision?
15:11:23 <sgallagh> FESCo ultimately granted us permission to bring it up but only to allow two module streams in the buildroot at first.
15:11:33 <sgallagh> (Rather than pulling in all the available default streams).
15:12:00 <langdon> avo and dwm, right? am i reading what you are saying correctly?
15:12:01 <sgallagh> This was in part due to the fact that if we unveiled it for all default streams, we'd break Java builds
15:12:20 <sgallagh> Due to the ant and maven default streams carrying stripped-down versions of some of their dependencies.
15:13:08 <sgallagh> The two module streams we're allowed to carry for now are `dwm:6.2` and `avocado:69lts`
15:13:37 <langdon> where "carry" = "make available to the buildroot" right?
15:13:40 <sgallagh> Those two were selected mostly because they're maintained by core Modularity staff
15:13:49 <sgallagh> langdon: Right, thanks for the clarification.
15:15:01 <sgallagh> So that's where we are; we need to work with nirik and mboddu to finish landing the buildroot compose and make sure that Koji is properly pulling it into the standard non-modular buildroot.
15:15:19 <sgallagh> EOM
15:15:44 <langdon> and this is rawhide, correct?
15:16:42 <sgallagh> Yes
15:16:49 <langdon> just trying to add color
15:17:04 <langdon> so.. per my q above .. how can we make it successful?
15:18:13 <sgallagh> langdon: I think we start by defining success
15:19:14 <sgallagh> ... That was your cue, langdon  :)
15:19:22 <langdon> sorry.. typing ;)
15:19:56 <langdon> thats what i have been thinking about.. how can we "show" the list of reqs you wrote in the blog post, the user experience "results" and the work being done where there are gaps between req != experience
15:20:54 <langdon> where ursa prime is just one part of that..
15:21:09 <langdon> i was kinda thinking like a manually maintained "burn down chart"
15:22:02 <langdon> in other words, do you not think your list of reqs is a definition of success? or do you just mean rewording it in terms of outcomes
15:22:04 <langdon> ?
15:22:05 <sgallagh> Sorry, this is the part where my conflict gets in the way :-/
15:23:23 <langdon> asamalik: do you have any ideas ^^ ?  you tend to be good at visualization
15:23:37 <langdon> i was also wondering if we could constructively ask the mailing lists
15:25:22 <asamalik> langdon: I think what you said could work, or just have a status per req, either showing to do / in progress / done or a rough percentage if that makes sense?
15:25:57 <langdon> asamalik: would that be "better" than an issue list (a la pagure)?
15:25:59 <asamalik> but I'm sure there will be details and surprises on the way
15:27:29 <asamalik> we could even give another chance to the Taiga board, making the epics slightly bigger to represent a specific deliverable — so we don't have 60 of them like on the old board... and it would show the progress automatically as we'd move cards
15:28:22 <asamalik> and I wouldn't make the card too detailed, definitely not representing single tasks, but rather representing a bigger distinct part — so there are not many of them
15:28:25 <langdon> asamalik: i think we need something more like https://status.fedoraproject.org/ ... "at a glance, here is our status"
15:28:30 <asamalik> make it more high level basically
15:28:48 <asamalik> right, that
15:28:58 <asamalik> that's basically what I was describing implemented in Taiga
15:29:08 <asamalik> or manually somehow
15:29:29 <langdon> asamalik: hmm... i wonder if we could and just have someone like me maintain it.. like don't use it for "work" just "reporting" ..
15:29:47 <asamalik> langdon: that was exactly what I meant, yes!
15:30:10 <asamalik> just to keep track of stuff, maybe some notes when needed
15:30:11 <langdon> ok.. ill play with that ..
15:30:32 <langdon> asamalik: yeah... i was thinking pointers/links to the "actual" work effort
15:30:42 <asamalik> yep
15:31:18 <asamalik> so we don't force people to use yet another tracker (which would fail anyway)
15:31:25 <langdon> right
15:31:39 <asamalik> and it will be consistent because it will be just you maintaining it, not arguing with anyone else who has different ideas about what a card is :)
15:31:41 <langdon> and even "screenshot" it in to the council stat-rep
15:31:47 <langdon> ha right
15:32:07 <asamalik> yep, or the epics view will show it quite nicely
15:32:16 <asamalik> and people could drill down for details
15:32:26 <asamalik> that would be related to status, not the work itself, so readable
15:33:22 <langdon> #action langdon to investigate better status reporting mechanism perhaps leveraging taiga
15:33:40 <asamalik> langdon++
15:33:43 <zodbot> asamalik: Karma for langdon changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:33:53 <langdon> sgallagh: so are you completely offline? or do you want to talk about upgrade path stuff?
15:34:07 <sgallagh> Give me two more minutes and I'll be properly back
15:34:21 <langdon> ok.. asamalik, can i assign you hold music?
15:34:42 <asamalik> langdon: how much do you hate yourself and everyone here?
15:34:49 <langdon> asamalik: lol
15:34:52 <langdon> literally
15:35:02 <langdon> people now looking at me funny
15:36:07 <sgallagh> Ok, let me read scrollback
15:36:16 <langdon> brb
15:36:22 <asamalik> haha, individuals laughing loudly never fail to make people look :P
15:37:30 <sgallagh> OK, so upgrade path
15:37:56 <sgallagh> #topic Upgrade Path Issue Recap
15:38:59 <langdon> back
15:39:17 <sgallagh> (Trying to organize my thoughts)
15:40:09 <sgallagh> Ultimately, we have two core issues with upgrades that each result in a variety of symptoms that users and packagers experience.
15:40:14 <sgallagh> The core issues are:
15:42:16 <sgallagh> #info Upgrade Issue 1: Installing software that comes from a module's default stream enables that module. At upgrade, the stream remains the same, even if the new OS release has changed the default. This behavior means that users do not get the experience they had with non-modular upgrades which is to follow the OS's opinionated defaults.
15:43:28 <langdon> do you want to #info or #link the bug for that?
15:43:47 <sgallagh> #info Upgrade Issue 2: When attempting to upgrade to a release where an enabled module stream has been retired and removed, the upgrade process fails with conflicts. This differs from the non-modular behavior of simply keeping the old content until and unless it starts to cause conflicts or else is Obsoleted.
15:44:37 <sgallagh> langdon: I'm not sure which bug to link, honestly. There are numerous bugs reporting the symptoms. I described the root cause
15:45:23 <langdon> sgallagh: ohh... i thought there was one specifically about dnf changing to follow a default if the user didn't choose it..
15:45:37 <langdon> but mayve that goes to the earlier status question as well
15:45:47 <langdon> i can track it (all of them) down
15:46:14 <sgallagh> Thanks
15:47:04 <langdon> #info tracking the bugs for these is not as simple as it may sound.. as a result, look to upcoming status report that was discussed earlier
15:47:11 <sgallagh> ack
15:47:17 <langdon> ok.. open floor? anyone have any comments/questions?
15:48:07 <langdon> #topic open floor
15:49:50 <langdon> ok.. going once
15:50:52 <langdon> and twice!
15:52:18 <langdon> and 3 times
15:52:44 <langdon> #endmeeting