15:00:00 <contyk> #startmeeting FESCO (2019-02-18)
15:00:01 <zodbot> Meeting started Mon Feb 18 15:00:00 2019 UTC.
15:00:01 <zodbot> This meeting is logged and archived in a public location.
15:00:01 <zodbot> The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:01 <zodbot> The meeting name has been set to 'fesco_(2019-02-18)'
15:00:03 <contyk> #meetingname fesco
15:00:03 <zodbot> The meeting name has been set to 'fesco'
15:00:05 <contyk> #chair nirik, bowlofeggs, jforbes, zbyszek, tyll, sgallagh, contyk, mhroncok, otaylor
15:00:05 <zodbot> Current chairs: bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh tyll zbyszek
15:00:07 <contyk> #topic init process
15:00:09 <contyk> .hello psabata
15:00:10 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:17 <jforbes> .hello2
15:00:18 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:00:29 <nirik> .hello kevin
15:00:30 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
15:00:31 <bowlofeggs> .hello2
15:00:33 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:00:48 <zbyszek> .hello2
15:00:49 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:01:28 <contyk> yay, quorum
15:01:47 <bowlofeggs> i love the smell of quorum in the morning
15:01:51 <bcotton> .hello2
15:01:52 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:01:55 <contyk> we have a lot to go through today
15:02:26 <contyk> so let's get started
15:02:32 <contyk> #topic #1974 Problematic blocker for F29: dnf 'offline' module tracking
15:02:34 <contyk> .fesco 1974
15:02:36 <contyk> https://pagure.io/fesco/issue/1974
15:02:36 <zodbot> contyk: Issue #1974: Problematic blocker for F29: dnf 'offline' module tracking - fesco - Pagure.io - https://pagure.io/fesco/issue/1974
15:03:01 <contyk> this one is pretty old; it wasn't fixed for f29 and likely won't be fixed for f30 either
15:03:23 <contyk> I know the DNF team has it on their agenda but probably won't be done in time for f30
15:03:42 <otaylor> .hello2
15:03:49 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:03:52 <zbyszek> Is anyone here speaking for the DNF team?
15:04:07 <contyk> let me ping them
15:04:47 <nirik> well, really the only things we can do are slip the release or just accept it's not going to be fixed for f30. ;(
15:05:35 <bcotton> or we could sit on someone's desk until they fix it :-)
15:05:49 <nirik> fesco sit in!
15:05:50 <bcotton> (not speaking metaphorically this time)
15:05:54 <jforbes> The last update we actually saw from the DNF team said they thought end of January was still a realistic timeframe. Is the code written?
15:06:00 <zbyszek> Well, it's not the kind of bug that could not be fixed by a few determined individuals in the next 3 months...
15:06:03 <contyk> there he is
15:06:23 <jmracek> Hi
15:06:33 <contyk> jmracek: we're discussing ${topic}; it's the modulemd storage / failsafe mechanism and planning for f30
15:06:48 <nirik> welcome jmracek. Thanks for coming.
15:06:50 <contyk> jmracek: as I understand it, this wouldn't be ready in time for f30 but we'd like your input here
15:08:15 <nirik> or if we need to gather more info we can revisit it / ask for updates in bug?
15:08:30 <jmracek> I don't think we can make it for Fedora 30. Of course if any contribution arrives from community, I will be happy to merge it.
15:08:57 <ttomecek> .hello2
15:08:58 <zodbot> ttomecek: ttomecek 'Tomas Tomecek' <ttomecek@redhat.com>
15:09:13 <contyk> so we prepared a technical proposal how to deal with this problem and discussed it with jmracek's team in December; they agreed to start looking at it in January but that date was moved because of other fires
15:09:40 <contyk> then January was full of conferences and other events
15:10:10 <nirik> yeah, and december holidays...
15:10:22 <jforbes> Is there another date? Personally, I don't mind treating this like we did with F29, but I also would rather not be having this same conversation again for F31
15:11:01 <contyk> jmracek: when do you think we could meet and discuss the failsafe mechanism proposal? would sometime this month sound realistic to you?
15:12:36 <jmracek> contyk: We already have a planning meeting on Wednesday, and we can discussed it personally.
15:13:03 <contyk> I think that's a yes then
15:13:13 <jmracek> Yes
15:13:40 <nirik> if you all could discuss wed and update the bug / our ticket that would be great
15:13:41 <contyk> so I'd be okay with deferring this to f31 as long as we sketch a specific plan before the end of the month
15:14:00 <bowlofeggs> agree with jforbes
15:14:03 <bowlofeggs> and contyk
15:15:04 <contyk> proposed #agreed As we're fairly sure this wouldn't be fixed in time for F30, we're moving this to F31. Modularity & DNF folks with prepare a specific implementation plan and will update the ticket.
15:15:29 <jforbes> +1
15:15:46 * nirik would kind of like to see the plan first, but ok
15:16:24 <bowlofeggs> contyk: +1
15:16:35 <zbyszek> nirik: agreed
15:16:35 <contyk> I think it's mostly about scheduling and prioritization rather than open technical questions
15:17:40 <contyk> there's also another DNF bug related to system upgrades that, if I had to choose, I'd like to see fixed instead
15:18:48 <contyk> otaylor: ?
15:19:22 <otaylor> contyk: you are asking about the discussion we had on fedora-modularity on friday?
15:19:31 <otaylor> contyk: or, are you prompting me for a vote on the proposal?
15:19:44 <contyk> otaylor: I'm prompting you to vote on the proposal
15:19:48 <otaylor> oh, sorry
15:19:57 <otaylor> +1
15:20:06 <zbyszek> I now realize how little time is left. So postponing is inevitable. So I'm full +1 for the proposal.
15:20:34 <contyk> #agreed As we're fairly sure this wouldn't be fixed in time for F30, we're moving this to F31. Modularity & DNF folks with prepare a specific implementation plan and will update the ticket (+6, 0, -1)
15:20:35 <otaylor> (I don't think trying to rush some untested code in last minute is going to improve the user experience for f30)
15:20:44 <contyk> agreed
15:20:50 <contyk> okay, next one
15:20:56 <contyk> #topic #2003 Ursa Major (modules in buildroot) enablement
15:20:58 <contyk> .fesco 2003
15:21:00 <contyk> https://pagure.io/fesco/issue/2003
15:21:00 <zodbot> contyk: Issue #2003: Ursa Major (modules in buildroot) enablement - fesco - Pagure.io - https://pagure.io/fesco/issue/2003
15:21:03 <contyk> it's our favorite
15:21:31 <contyk> so we kinda sorta have a plan how to put modules in the non-modular buildroot without Ursa Major
15:21:33 <bowlofeggs> so i heard some rumours that this wasn't necessary with a new plan. any updates on that/
15:22:06 <contyk> we talked about this in person at DevConf and I promised to prepare a writeup people would ack before we move forward; I'm super late here
15:22:17 <contyk> I'll have it ready today or tomorrow
15:22:47 <contyk> either way, it requires changes to both MBS and Koji, which means it will not be ready for f30
15:23:03 <contyk> so I guess the question here is -- what do we do about those java packages?
15:23:05 <bowlofeggs> are we in ok shape for EPEL at least?
15:23:28 <contyk> bowlofeggs: EPEL requires the very same changes
15:23:29 <bowlofeggs> nothing stops volunteers from unretiring/unorphaning them, right?
15:23:43 <contyk> right
15:23:47 <bowlofeggs> other than lack of volunteers ☺
15:23:52 <nirik> for epel8beta we are going to first do a non modular thing, then modules when the above is ready.
15:24:19 <contyk> yeah, but we need modules to build the non-modular thing, most likely
15:24:45 <bowlofeggs> i don't have any ideas for what we can do about the java packages. sounds like they need someone motivated to do the work
15:25:06 <contyk> I was thinking we could just... not retire them
15:25:19 <nirik> some of them were picked up I thought...
15:25:24 <bowlofeggs> well they'd need someone to at least adopt them, right?
15:25:36 <bowlofeggs> yeah some were picked up
15:25:36 <contyk> to make it easier on people; of course that means they would be unmaintained but it would be easier for volunteers and provenpackagers to fix them if needed
15:25:39 <bowlofeggs> i assume not all though
15:25:52 <zbyszek> contyk: agreed. I think we can add an exemption to the usual orphaining process.
15:26:03 <bowlofeggs> we could assign them all to contyk ☺
15:26:16 <contyk> I was going to suggest nirik
15:26:19 <bowlofeggs> ahahah
15:26:38 <nirik> ha. No thanks.
15:26:52 <bowlofeggs> i think 've had the misfortune of adopting too many packages in my past to accept any more myself
15:27:05 <bowlofeggs> i got almost all of luke's packages when he left
15:27:09 <nirik> I think the important ones to other folks will get picked up...
15:27:29 * contyk remembers the time when he had the most packages in Fedora
15:28:00 <nirik> it would be nice if this hadn't happened until we had ursa major replacement in place... but such is life.
15:28:19 <bowlofeggs> there is that group that wants to form around this
15:28:24 <bowlofeggs> perhaps they would like to adopt these
15:28:33 <bowlofeggs> (on devel list)
15:28:52 <contyk> so how about we say they're an exception and won't be retired for f31/rawhide?
15:29:08 <nirik> I don't know that I like excepting them...
15:29:08 <contyk> these group can still take them but the rest will not disappear, it will just be orphaned
15:29:11 <bowlofeggs> i think i would prefer to follow the policy
15:29:27 <nirik> if we change the unretirement process, they could be unretired longer
15:29:28 <bowlofeggs> if they are important, they should be looked after
15:29:39 <bowlofeggs> if nobody wants to look after them, they must not be that important
15:29:43 <bowlofeggs> that's my logic anyway
15:29:45 <contyk> I'm worried hundreds of necessary packages will suddenly disappear and people will have to go through the review process to get them back
15:30:01 <contyk> it's just people not noticing until it's too late
15:30:03 <nirik> well, already you have 2 weeks...
15:30:04 <bowlofeggs> i would +1 making that part easier
15:30:10 <nirik> but there's a proposal to make it longer
15:30:47 <jforbes> Yup, just no agreed upon definition of "longer"
15:30:53 <zbyszek> The reason is why we could except them is that we "know" that they are maintained in the modules, so maintainership could be mostly a matter of copying the changes.
15:31:11 <zbyszek> So if there's some "grave" bug, chances are somebody will volunteer a fix.
15:31:33 <contyk> +1
15:31:41 <otaylor> I'm really missing somethig obvious here - we don't have per-branch ownership, so how is 'maintained in the modules' different from maintained in dist-git?
15:31:44 <nirik> but if no one is doing that... how does it matter?
15:31:52 <bowlofeggs> if it were really that easy, wouldn't the original maintainer just keep doing it though?
15:32:07 <bowlofeggs> i would think it must still not be that easy. sounds at least tedious to me
15:32:26 <bowlofeggs> and yeah, nobody is doing it if it is orphaned
15:32:38 <bowlofeggs> we have a process for this, i think we should stick to it
15:33:21 <contyk> so your proposal is "do nothing and let people who need them handle it"?
15:33:46 <bowlofeggs> haha, well i would phrase it as "let our usual processes handle this - this is what they are designed for"
15:33:48 <bowlofeggs> but yes
15:34:18 <bowlofeggs> i don't think we need to do anything out of the ordinary here
15:35:07 <nirik> +1
15:35:30 <zbyszek> OK, but can we revisit this question *before* all the java packages are orphaned in 5 weeks?
15:35:30 <contyk> I'm now curious if these are going completely away then; as noted above, if they were in modules, they wouldn't be orphaned
15:35:33 <nirik> but we should be ready to do a bunch of unretirements when/if people find they need something after all
15:35:53 <contyk> just retired from master
15:36:01 <contyk> or maybe I'm misunderstanding the situation
15:36:23 <nirik> they are going away as buildrequires mostly
15:36:55 <nirik> but I guess also from end users as the modules only use those to build things
15:37:09 <nirik> or are they publishing those too?
15:37:19 <contyk> okay, but that means the module maintainer should still own them
15:37:28 <contyk> I think we discussed that a couple of meetings ago
15:37:39 <zbyszek> nirik: we're also destroying the experience of Fedora as developer workstation
15:37:49 <bowlofeggs> zbyszek: i wouldn't mind talking about it again before they are retired
15:38:45 <contyk> should we discuss this next week then?
15:38:49 <nirik> zbyszek: sure, but it's hard to force people to maintain things they don't want to maintain
15:38:50 <otaylor> zbyszek: I *think* most Java developers use maven, and not packaged depenendencies, but yes, it's an important general consideration
15:39:26 <zbyszek> otaylor: in my experience, not everything is available in maven, for example in the scientific world.
15:39:48 <bowlofeggs> is this an appropriate time to make java jokes?
15:40:01 <zbyszek> It was very nice to be able to specify the environment using 'dnf install'.
15:40:05 <tyll_> .hello till
15:40:07 <zodbot> tyll_: till 'Till Maas' <opensource@till.name>
15:40:25 <ignatenkobrain> zbyszek: except that on non-rawhide, java packages are outdated ;)
15:40:49 <nirik> well, maven and ant are available to end users as modules, just other stuff is not I guess.
15:40:52 <otaylor> zbyszek: that should still be available with modular java, just takes more specialized knowledge then 'dnf install <thing I want>'
15:41:21 <contyk> not all of it would, if I understand it correctly
15:41:41 <otaylor> zbyszek: Fedora toolbox could potentially be a thing that knows how to set up a cojntianer with the right modules
15:42:10 <zbyszek> otaylor: but that seems like a gigantic step backwards
15:42:36 <zbyszek> I mean, I know that this is just software, so everything is always "possible", but meh.
15:42:53 <otaylor> zbyszek: Not necessarily - gives more power as well .... like being able to use the Java packages from rawhide without upgrading your system to rawhide
15:43:19 <otaylor> zbyszek: but it's only a step forward if we put real effort into making it nice, and not just wave our hands around :-)
15:43:30 <contyk> :)
15:43:40 <zbyszek> Yeah,
15:43:49 <bowlofeggs> i keep feeling bad because i haven't really done much with modularity, so it's still very abstract to me
15:44:12 <bowlofeggs> like i get the high level picture (well, i think i do?), but the details are very hazy to me
15:44:24 <contyk> it's magical
15:44:49 <zbyszek> Anyway, IIUC, contyk will prepare an alternate proposal within a few days.
15:44:56 <zbyszek> Should we just wwait for that and revisit?
15:45:13 <jforbes> I think so
15:45:18 <contyk> yeah, but the implementation will likely take time
15:45:24 <tyll> bowlofeggs: to me it seems not very ready in many areas
15:45:43 <contyk> I'd wanted to know what happens if it's not ready for f30 in this particular case
15:45:59 <contyk> and zbyszek also has a point; that will be valid no matter what
15:46:30 <contyk> but that's up to the maintainers, I'd say
15:46:54 <bowlofeggs> tyll: sometimes i feel that way too, though i also don't know if i'm qualified to say that since i know so little about it
15:47:17 <bowlofeggs> FESCo: where we get to make decisions on things we often aren't qualified to decide on
15:47:28 <contyk> proposed #agreed contyk will prepare & share a proposal solving the buildroot problem without Ursa Major. We will revisit next week.
15:47:32 <bowlofeggs> see probably also: any governing body
15:47:42 <bowlofeggs> contyk: +1
15:47:43 <zbyszek> contyk: +1
15:47:48 <jforbes> contyk: +1
15:47:48 <tyll> contyk: +1
15:47:58 <otaylor> contyk: +1
15:48:09 <nirik> +1
15:48:25 <contyk> #agreed contyk will prepare & share a proposal solving the buildroot problem without Ursa Major. We will revisit next week. (+7, 0, -1)
15:48:34 <contyk> okay
15:48:37 <zbyszek> No -1?
15:48:40 <tyll> bowlofeggs: This is why we can ask questions about technical details to get clarity
15:48:46 <contyk> oh
15:48:48 <contyk> #undo
15:48:48 <zodbot> Removing item from minutes: AGREED by contyk at 15:48:25 : contyk will prepare & share a proposal solving the buildroot problem without Ursa Major. We will revisit next week. (+7, 0, -1)
15:48:53 <contyk> #agreed contyk will prepare & share a proposal solving the buildroot problem without Ursa Major. We will revisit next week. (+7, 0, -0)
15:48:55 <bowlofeggs> tyll: indeed ☺
15:49:07 <contyk> #opitc #2078 F30 Change: MongoDB removal
15:49:10 <contyk> .fesco 2078
15:49:12 <contyk> https://pagure.io/fesco/issue/2078
15:49:12 <zodbot> contyk: Issue #2078: F30 Change: MongoDB removal - fesco - Pagure.io - https://pagure.io/fesco/issue/2078
15:49:38 <nirik> +1 (sorry I didn;'t vote in ticket)
15:50:00 <bowlofeggs> i'm +1 in ticket
15:50:04 <bowlofeggs> and i'm +1 in irc
15:50:08 <bowlofeggs> and i'm +1 irl
15:50:08 <contyk> tyll -- you think this needs more discussion?
15:50:33 * zbyszek voted +1
15:50:35 <bowlofeggs> i'll be surprised if there doesn't end up being a fork of mongodb that sticks to the old license
15:50:39 <tyll> contyk: no, I just want to make sure that everyone who voted before the discussion still agrees after the discussion
15:51:44 <contyk> not sure how to count it then
15:52:49 <contyk> tyll: would you like to give it another week so that everyone has a chance to see the new comments?
15:53:10 <tyll> contyk: we can decide this with the people here IMHO
15:53:10 <zbyszek> Well, we have quorom. We can vote again if people have doubts.
15:53:33 <tyll> not sure if there is anyone who did not agree after this discussion
15:53:42 <tyll> the discussion
15:53:46 <contyk> true; I'll discard the votes in the ticket and let's vote here
15:54:10 <zbyszek> Nobody objected in the ticket...
15:55:08 <tyll> also it is now 7 days after the list of pkgs was amende
15:55:10 <tyll> amended
15:55:18 <tyll> IMHO we are good to approve it now
15:55:24 * nirik nods
15:56:01 <otaylor> +1 for me too on that
15:56:09 <zbyszek> +1 ftr
15:56:10 * contyk is still confused who to count as +1 and who could potentially change their mind, though, according to tyll's comment
15:56:23 <contyk> so please
15:56:36 <contyk> porposed #agreed F30 Change: MongoDB removal is approved.
15:56:40 <nirik> I think count all the +1s in ticket and the +1s here? or we could just all vote in ticket and you can use that when you finish?
15:56:50 <nirik> whatever works. +1 here.
15:56:53 <tyll> contyk: +1
15:56:59 <zbyszek> contyk: +1
15:58:13 <contyk> jforbes, bowlofeggs, otaylor: ftr ^ ?
15:58:26 <otaylor> +1
15:58:33 <bowlofeggs> contyk: as said above, i'm +1 in ticket, irc, and irl ☺
15:59:17 <contyk> #agreed F30 Change: MongoDB removal is approved. (+6, 0, -0)
15:59:27 <contyk> #topic #2046 Change process: Releng impact tickets are tedious and possibly contribute to
15:59:30 <contyk> overwhelm releng
15:59:32 <contyk> .fesco 2046
15:59:34 <contyk> https://pagure.io/fesco/issue/2046
15:59:34 <zodbot> contyk: Issue #2046: Change process: Releng impact tickets are tedious and possibly contribute to overwhelm releng - fesco - Pagure.io - https://pagure.io/fesco/issue/2046
16:00:31 <zbyszek> So we're at +4 for nirik's proposal
16:00:52 <contyk> +1 here
16:00:58 <tyll> IMHO it is most important to know if mboddu wants a new ticket for every change or not. If not I am fine with the new proposal.
16:01:55 <otaylor> +1  for nirik's proposal
16:01:59 <zbyszek> I'd take the fact that mboddu did not reply in the ticket at all as a strong sign that less tickets for him to process would be a good idea.
16:02:24 <bcotton> tyll: when i talked to mboddu at DevConf, he was in favor of reducing the number of tickets he has to ack
16:02:36 <tyll> bcotton: ok, thx for the info
16:02:37 <bowlofeggs> zbyszek: haha +1
16:02:38 <tyll> +1 then
16:03:19 <jforbes> still with my +1 from ticket (for Mongo as well)
16:03:31 <bowlofeggs> i +1'd in ticket
16:03:47 <mboddu> tyll: I prefer filing the tickets for system-wide changes but not for self contained changes, for self contained changes adding a line like "up to change requestor to create a ticket against releng if they think work is needed from releng"
16:03:59 <contyk> so that's +8
16:04:36 <contyk> #agreed System wide changes remain the same for now. For self contained changes if the proposal owner(s) think releng involvement is needed, they open a ticket, but it is not mandatory, Anyone who feels releng should be notified of and discuss the change can file a releng ticket anytime. (+8, 0, -0)
16:04:49 <contyk> #topic #2067 tss2 package ownership
16:04:52 <contyk> .fesco 2067
16:04:54 <contyk> https://pagure.io/fesco/issue/2067
16:04:54 <zodbot> contyk: Issue #2067: tss2 package ownership - fesco - Pagure.io - https://pagure.io/fesco/issue/2067
16:04:56 <mboddu> contyk: +1
16:05:51 * nirik isn't sure what needs to be done here.
16:05:51 <contyk> +1 to assigning to snits
16:06:08 <bowlofeggs> shouldn't we do the usual process here?
16:06:11 <nirik> sure, +1 to reassigning if we know they aren't there.
16:06:14 <bowlofeggs> nonresponsive maintainer?
16:06:24 <bowlofeggs> at least the part of mailing devel
16:06:29 <bowlofeggs> since th address bounces
16:06:29 <nirik> there's a quick path for if we know their email is invalid
16:06:32 * nirik looks it up
16:06:33 <bowlofeggs> ah
16:06:51 <nirik> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers?rd=PackageMaintainers/Policy/NonResponsiveMaintainers#Notes_for_invalid_email_addresses
16:07:06 <nirik> it's the same thing we do when people leave red hat and their address becomes invalid.
16:07:19 <bowlofeggs> yeah devel list
16:07:23 <bowlofeggs> so we still need to write devel list
16:07:26 <zbyszek> I'd prefer to assign snits as a comaintainer now, and do the full switch after we have had the email to devel-list
16:07:55 <nirik> zbyszek: +1 adding a co-maintainer should be fine.
16:08:02 <nirik> who is going to do the devel list post?
16:08:15 <zbyszek> I'll do it.
16:08:29 <bowlofeggs> yeah +1 to comaintainer
16:09:06 <jforbes> +1 comaintainer as well
16:10:31 <zbyszek> .fasinfo honclo
16:10:32 <zodbot> zbyszek: User: honclo, Name: None, email: lo1@us.ibm.com, Creation: 2016-03-21, IRC Nick: None, Timezone: None, Locale: None, GPG key ID: None, Status: active
16:10:36 <zodbot> zbyszek: Unapproved Groups: gitabout-fedora security-team rpm-software-management
16:10:39 <zodbot> zbyszek: Approved Groups: packager fedorabugs cla_ibm cla_done cla_fpca
16:11:00 <contyk> +5 so far
16:11:01 <nirik> want me to add them ? or someone else wants to?
16:11:01 <zbyszek> For heaven's sake, can somebody give me the name of honclo?
16:11:26 <nirik> they set 'private' on their fas account, so it won't share that info...
16:12:03 <tyll> The ticket says it is Vicky, does it not?
16:12:11 <zbyszek> Yeah, but Vicky who?
16:13:32 <nirik> perhaps we should ask for clarification in the ticket... it's a bit confusing to me from a quick read
16:13:34 <contyk> bowlofeggs, zbyszek, otaylor, tibbs: +1 to adding the comaintainer?
16:13:36 <tyll> Hon Ching(Vicky) Lo
16:13:49 <bowlofeggs> contyk: +1
16:13:53 <zbyszek> contyk: I think I proposed that, so I'm +1 automatically
16:14:00 <tyll> according to https://fedorapeople.org/~honclo/tss2.spec
16:14:11 <zbyszek> Thanks tyll.
16:14:33 <contyk> zbyszek: well, it's proposed in the ticket... okay
16:14:56 <otaylor> +1
16:15:49 <contyk> #agreed Agreed to add snits as a comaintainer for tss2 (+7, 0, -0)
16:16:03 <contyk> #topic #2071 F30 Change: Firefox Wayland By Default On Gnome
16:16:06 <contyk> .fesco 2071
16:16:08 <contyk> https://pagure.io/fesco/issue/2071
16:16:08 <zodbot> contyk: Issue #2071: F30 Change: Firefox Wayland By Default On Gnome - fesco - Pagure.io - https://pagure.io/fesco/issue/2071
16:16:41 * zbyszek was +1 in the ticket
16:16:43 <contyk> +6 in the ticket, +1 more from me
16:16:45 * nirik was +1 in ticket.
16:16:47 <bowlofeggs> i was +1 in ticket
16:17:19 <zbyszek> So, I upgraded to the upstream nightly, and unfortunately many (most?) of the bugs that are present in the F29 version are still present there.
16:17:51 <bowlofeggs> hmm
16:17:54 <zbyszek> But at least upstream is aware of the bugs
16:17:58 <nirik> I haven't been hitting too much... there's some odd focus issues, but otherwise it seems to work ok here.
16:18:04 <bowlofeggs> zbyszek: would you characterize it as significant?
16:19:15 <zbyszek> bowlofeggs: many menus appear trimmed to a quadrant, so you see 25% of area. Unless you know the keyboard shortcuts, many things are impossible.
16:19:27 <zbyszek> So yeah, I'd characterize them as significant.
16:19:28 <contyk> that's pretty bad
16:19:30 <bowlofeggs> that does sound ungoog
16:19:32 <bowlofeggs> *ungood
16:19:43 <zbyszek> A new nightly came out today, but I haven't downloaded it yet.
16:19:47 <bowlofeggs> that makes me hesitate
16:19:57 <bowlofeggs> i think i might be -1
16:20:09 <bowlofeggs> FF is the default browser in the workstation edition
16:20:10 <zbyszek> Well, I think we should try it, rollback in this case is very easy.
16:20:24 <bowlofeggs> that's true
16:20:34 <nirik> weird. I do not seethat here
16:21:05 * tibbs reads scrollback....
16:21:07 <nirik> zbyszek: does it still happen for you with a new profile?
16:21:10 <zbyszek> nirik: Do you have a hidpy main screen?
16:21:14 <contyk> tibbs: apologies, I meant to tag tyll :|
16:21:15 <nirik> yes
16:21:32 <nirik> dimensions:    3840x2160 pixels (1016x572 millimeters)
16:21:48 <tyll> contyk: where?
16:21:58 <tibbs> I'm always +1 for comaintainers, but I don't know why anyone would ask me.
16:22:10 <contyk> tyll: the previous vote
16:22:14 <contyk> tibbs: :)
16:22:45 <bowlofeggs> i guess i'll stay +1 due to the ease of rollback and due to nirik not experiencing it
16:22:48 <tyll> contyk: ah, ok, I'm +1, too ;-)
16:22:52 <bowlofeggs> we can let QA see what they think ☺\
16:23:30 <contyk> otaylor: ?
16:23:46 <zbyszek> nirik: just tested, at least the weird menu positioning and visual glicthes are there
16:23:55 <nirik> huh, odd.
16:24:10 <zbyszek> I don't get the menu effect right now, but it's racy...
16:24:36 <otaylor> contyk: I'm hestitant to vote, since I havne't been able to try it out myeslf, and form an informed opinion, but +1 since my default is to trust stransky's opinion
16:25:16 * contyk nods
16:25:17 <otaylor> I don't think visual glitches are going to be hard to fix, if we get on top of reproducing them, and get stransky and if necessary the mutter/gnome-shell people involved
16:25:19 <nirik> I'm also assuming users can choose back to x11 if they like
16:25:36 <ignatenkobrain> FYI, I'm running FF-on-wayland and it seems to be working fine
16:25:38 <contyk> and we can always revert it if it's not fixed before final
16:25:44 <ignatenkobrain> there are sometimes positioning issues, but most of the time it is good
16:25:44 <otaylor> that's less of a concern to me compared to some major missing feature
16:25:59 <nirik> right now there's a firefox and a firefox wayland, if they switch this to firefox and firefox x11 it would be ideal.
16:26:53 <contyk> #agreed F30 Change: Firefox Wayland By Default On Gnome is approved but might get reverted if the glitches are not fixed in time for F30 final (+8, 0, -0)
16:27:01 <otaylor> note that on silverblue, it's harder to switch at the moment, since firefox is baked in, but silverblue users are more tolerant of stuff being a little rough :-)
16:27:21 <contyk> four more
16:27:30 <contyk> #topic #2072 Unable to implement FESCO policy decision! ( https://pagure.io/fesco/issue/1935)
16:27:32 <contyk> .fesco 2072
16:27:34 <contyk> https://pagure.io/fesco/issue/2072
16:27:35 <zodbot> contyk: Issue #2072: Unable to implement FESCO policy decision! ( https://pagure.io/fesco/issue/1935) - fesco - Pagure.io - https://pagure.io/fesco/issue/2072
16:28:07 <nirik> we talked about this at the last releng meeting.
16:29:06 <nirik> https://meetbot-raw.fedoraproject.org/teams/releng/releng.2019-02-14-17.00.log.html
16:29:29 <nirik> we had questions about the timing...
16:29:44 <nirik> mboddu was going to file a ticket.
16:30:10 * mboddu did file a ticket and searching
16:30:17 * nirik can't find it now. ;)
16:30:25 <tyll> https://pagure.io/fesco/issue/2090
16:30:30 <mboddu> https://pagure.io/fesco/issue/2090
16:30:34 <mboddu> Thanks tyll :)
16:31:30 <nirik> so, 8 weeks seems an odd number... and doing it such that we have to retire things in both branched and rawhide seems like more work
16:32:12 <tyll> IMHO the retirement should happen before branching and if we make it possible to unretire pkgs for longer than two weeks IMHO 4-6 weeks announcements should be enough IMHO
16:32:40 <nirik> (also we didn't get to this process yet, so... what to do about f30?)
16:32:48 <mboddu> So, in that case, we have start processing them before mass rebuild and retire them before branchign
16:33:48 <nirik> yeah.
16:34:23 <bowlofeggs> nirik:  wouldn't this be automated to address the more work bit?
16:34:25 <contyk> should we close 2072 and discuss in 2090?
16:34:48 <bowlofeggs> i do feel like retiring long after branching is not good for other reasons though
16:34:55 <nirik> bowlofeggs: sure, but it means we have to handle 2 branches, more looking at bugs (we can't just look at rawhide, we have to look at the branched bugs, etc)
16:35:09 <bowlofeggs> true
16:35:27 <bowlofeggs> it also defeats part of the point of branching, imo, which is stabilizing
16:35:36 <nirik> IMHO I would like to retire with enough time before branching that people could see that they need something and bring it back and fix it.
16:35:47 <bowlofeggs> if our policy changes the branch then it destabilizes it during a period we are trying to stabilize it
16:35:50 <mboddu> nirik: +1
16:35:51 <jforbes> nirik: that seems wise
16:36:00 <bowlofeggs> nirik: +1
16:36:25 <contyk> nirik: +1
16:36:28 <nirik> I have a feeling this is going to be a painfull process...
16:36:29 <zbyszek> OK, so is everybody on board with 4 weeks of delay starting 5 weeks before branching?
16:36:50 <contyk> it sounds reasonable
16:37:10 <nirik> sounds good.
16:37:15 <mboddu> So, how about, after N-2 retirement, we will run the process and start sending notices for 4 and then retire them, that gives at least a month to 2 months of time before branching
16:37:23 <nirik> and perhaps we should do some 'test' runs on rawhide after branching this cycle.
16:37:30 <tyll> zbyszek: how about 6 weeks before branching to avoid putting too much stuff in just the one week before branching
16:37:39 <zbyszek> tyll: works for me too
16:37:46 <nirik> tyll: fine with that as well.
16:37:46 <bowlofeggs> zbyszek: +1
16:37:49 <jforbes> I think we approved the overall idea, I would be happy to say let releng and huzaifas work out the specific timeline
16:37:51 <zbyszek> I like mboddu's idea too.
16:37:51 <bowlofeggs> tyll: also +1
16:38:01 <zbyszek> jforbes: Also +1
16:38:08 <otaylor> +1
16:38:14 <bowlofeggs> mboddu: except that sometimes N-2 can slip and N comes sooner
16:38:15 <nirik> +1's all around! :)
16:38:26 <bowlofeggs> better to schedule it relative to N than to N-2, IMO
16:38:27 <bcotton> +1 to +1s
16:38:49 <mboddu> Well, N-2 retirement is dependent of N release, its always retired 4 weeks after N release
16:38:57 <bcotton> bowlofeggs: agreed. from an schedule implementation perspective, it's always easier to tie tasks to milestones in N
16:38:57 <contyk> jforbes: do you want them to figure it out in 2090?
16:39:15 <otaylor> [ Would think that *coordinated* automation of package retirement for security, orphaned dependences, FTBS, etc, woudl be great - separate nag mails, scripts for releng to run, etc. makes it hard on anybody ]
16:39:17 <contyk> I'd just closed 2072 pointing to the 2090 discussion
16:39:39 <nirik> otaylor: yeah, thats true too.
16:39:51 <jforbes> contyk: that works
16:39:57 <nirik> and there's a lot of overlap in those scripts I would imagine
16:40:06 <bowlofeggs> proposal: jforbes' idea about letting releng and huzaifas come up with a proposal in #2090 and revisit
16:40:11 <mboddu> bowlofeggs: So, indirectly its related to N, but I see your point with schedule, so, lets says 6 weeks after N release start the process and intimate people for 4 weeks and 5th is the retirement, which gives between a month to 2 before branching
16:40:37 <nirik> mboddu: +1
16:40:40 <contyk> bowlofeggs: +1
16:40:50 <bowlofeggs> mboddu: right, but i'm saying it should be related to the schedule of the next release, not to the schedule of the last release
16:40:52 <nirik> and also at that time people are done with N and can focus on fixing things.
16:41:03 <bowlofeggs> i.e., it should be framed as x weeks *before* branching
16:41:11 <bowlofeggs> not x weeks *after* the previous release
16:41:28 <bowlofeggs> otherwise you end up with oddities if schedules change between releases (and they do)
16:41:30 <mboddu> Sure
16:41:42 <contyk> 19 minutes, three more topics to go
16:41:45 <nirik> so 8 weeks before branching, 4 weeks of nags, ?
16:41:51 <bowlofeggs> nirik: sure
16:41:55 <zbyszek> +1 to bowlofeggs proposal
16:41:59 <nirik> but yeah, we can come up with something and update the ticket
16:42:03 <mboddu> I will keep it to N release
16:42:16 <nirik> bowlofeggs: +1
16:42:16 <zbyszek> Let's vote in the ticket.
16:42:27 <jforbes> just to reiterate, my proposal was not to hash this out in the meeting here
16:42:28 <nirik> sure, sounds good.
16:42:48 <bowlofeggs> yeah let's let the specifics be hammered out in ticket and move on
16:43:13 <contyk> I don't think this needs a formal vote
16:43:20 <zbyszek> No.
16:43:22 <contyk> I don't see anyone really objecting, so just an info
16:43:30 <bowlofeggs> agreed
16:43:49 <contyk> #info huzaifas and releng will discuss the solution in #2090; FESCo will revisit next week
16:43:51 <mboddu> I will update the ticket with my proposal and we can talk there
16:44:08 <contyk> #topic #2077 F30 Change: SWID tag enablement
16:44:10 <nirik> thanks mboddu
16:44:11 <contyk> .fesco 2077
16:44:12 <zodbot> contyk: Issue #2077: F30 Change: SWID tag enablement - fesco - Pagure.io - https://pagure.io/fesco/issue/2077
16:44:13 <contyk> https://pagure.io/fesco/issue/2077
16:44:37 <nirik> +1, sounds fine
16:45:10 <contyk> +1 from me as well
16:45:17 <tyll> +1
16:45:33 <jforbes> +1
16:46:13 <zbyszek> +1
16:46:17 <otaylor> +1
16:46:24 <contyk> bowlofeggs: ^ ?
16:47:01 <bowlofeggs> +1
16:47:21 <contyk> #agreed F30 Change: SWID tag enablement approved (+9, 0, -0)
16:47:22 <zbyszek> I support ignatenkobrain's idea of doing this upstream, but upstream doesn't seem inclined to ansewr
16:47:37 <contyk> #topic #2088 Late F30 Change – “dnf --best” as default behavior
16:47:39 <contyk> .fesco 2088
16:47:41 <contyk> https://pagure.io/fesco/issue/2088
16:47:41 <zodbot> contyk: Issue #2088: Late F30 Change – “dnf --best” as default behavior - fesco - Pagure.io - https://pagure.io/fesco/issue/2088
16:47:57 <ignatenkobrain> zbyszek: I think everyone is busy 😞
16:48:42 <nirik> I think it's going to be confusing to have --skip-broken and --nobest
16:49:07 <jforbes> nirik: agreed
16:49:31 <otaylor> Are people comfortable, that, to the best of current knowledge, this is only going to apply to dnf from the commadn line and not to GNOME Software?
16:49:39 <nirik> but we can try and communicate that as best we can... definitely release notes, but also some blogs and other such things.
16:49:49 <otaylor> https://pagure.io/fesco/issue/2088#comment-553962
16:49:50 <bowlofeggs> nirik: also weird that one has a - and the other does not ☺
16:49:51 * nirik is +1
16:50:13 <ignatenkobrain> can we have it disabled for rawhide at least?
16:50:37 <bowlofeggs> otaylor: i kind of assume they work differently today in various ways anyway, though tbh i don't really know
16:51:02 <contyk> otaylor: is that true? I would expect GNOME Software to just use whatever libdnf tells it to use (via pkgkit)
16:51:02 <bowlofeggs> will this result in hiding real errors from users?
16:51:18 <contyk> ignatenkobrain: I'd also like to see this disabled in Rawhide
16:51:21 <ignatenkobrain> bowlofeggs: --nobest will allow installation of older package in order to satisfy dependencies, --skip-broken will just skip installation of anything like that
16:51:43 <contyk> I'd also drop the --nobest shorthand and just rely on --setopts if you need it
16:51:54 <ignatenkobrain> for me, this is huge drawback even in stable release
16:51:55 <otaylor> contyk: PackageKit is an independent user of libdnf - it doesn't call dnf on the command line (as I understand, there's also some weirdness with libdnf with two API's - a C one and C++ one)
16:52:02 <ignatenkobrain> it is like getting back to old yum times
16:52:26 <nirik> bowlofeggs: the current setup does that. ;)
16:52:30 <bowlofeggs> so --best will highlight dependency problems more than dnf does today?
16:52:38 <ignatenkobrain> Kinda feels that it is soon will be time to drop libsolv usage from dnf because it is mostly not used for its features
16:52:41 <bowlofeggs> nirik: ah ok, so backwards of whati though
16:52:43 <bowlofeggs> t
16:53:10 <ignatenkobrain> bowlofeggs: right now what you see on rawhide is:   - nothing provides python3.7dist(botocore) = 1.12.91 needed by awscli-1.16.101-1.fc30.noarch
16:53:27 <ignatenkobrain> after change, it will just show this error message and won't allow you to do an update, until you pass --skip-broken
16:53:34 <nirik> --best makes it try only the newest and fail if it can't do that, by default it just hides those/drops them if it can't
16:53:57 <nirik> ignatenkobrain: I possibly broke that yesterday, but I didn't think I did...
16:54:10 <bowlofeggs> ignatenkobrain: yeah i see those all the time
16:54:12 <bowlofeggs> haha
16:54:23 <bowlofeggs> ok, so it just turns that into a non-zero exit code and a halt?
16:54:46 <nirik> rawhide gating will save us all! :)
16:54:53 <bowlofeggs> this is framed as being better for user security - is that just because it forces the user to see the error?
16:55:08 <ignatenkobrain> nirik: bowlofeggs now imagine that you have your custom package which depends on puppet < 5, and you have custom repo which has puppet-4-xyz.rpm... previously, libsolv would just select that rpm from non-fedora repo and user will be able to install his app
16:55:10 <otaylor> bowlofeggs: I'm don't think it's being framed as better for *desktop* user security
16:55:25 <ignatenkobrain> after change, he would have to use --setopt=best=0 in order to install his RPM
16:55:39 <ignatenkobrain> from my POV, this is one of few things people love DNF for
16:56:04 <otaylor> bowlofeggs: I don't think the self-maintained workstation was really considered here
16:56:04 <bowlofeggs> otaylor: fair
16:56:14 <bowlofeggs> yeah, it sounds like it's just the CLI
16:56:46 <bowlofeggs> i'm not sure the security argument is hugely compelling to me
16:56:47 <otaylor> bowlofeggs: Even from the CLI, it's not clear the new experience is better if you want to "update your system"
16:56:55 <bowlofeggs> yeah
16:57:04 <nirik> so right now, I have readline broken here... if I just run dnf it shows that it's skipping that...
16:57:10 <contyk> that's the point, I think
16:57:16 <nirik> if I run --best it shows the error and exits
16:57:19 <contyk> the current configuration silently hides updates from you
16:57:27 <ignatenkobrain> nirik: but it still updates other packages, right?
16:57:28 <bowlofeggs> i think you would want to uypdate what you can, for security, right?
16:57:31 <nirik> well, it's not silent tho.
16:57:39 <tyll> does dnf report problem pkgs with "--nobest"?
16:57:42 <ignatenkobrain> (those which do not depend on libreadline.so.7)
16:57:43 <nirik> Skipping packages with conflicts:
16:57:43 <nirik> (add '--best --allowerasing' to command line to force their upgrade):
16:57:43 <nirik> readline                             x86_64      7.0-13.fc30                          rawhide      182 k
16:57:43 <nirik> readline                             x86_64      8.0-2.fc30                           koji         191 k
16:57:50 <bowlofeggs> like it seems bad that it is refusing to update pacakges that it could just because of a few it can't, from a security angle
16:57:57 <ignatenkobrain> bowlofeggs: +1
16:57:59 <bowlofeggs> what if one of the ones it could is an important security update?
16:58:25 <contyk> nirik: it is silent to scripts
16:58:33 <bowlofeggs> contyk: that's true
16:58:34 <nirik> true
16:58:50 <ignatenkobrain> bowlofeggs: I don't think there is right answer, but I showed example with custom repo which has older version of package and dnf would be able to resolve dependencies properly (even by installing older package).
16:58:51 <bowlofeggs> so for automated "users" this is an improveent, but for human (CLI) users, it's not, imo
16:58:54 <ignatenkobrain> which is really good UX
16:59:00 <nirik> is dnf-automatic changing behavior too?
16:59:02 <ignatenkobrain> and now we disallow this
16:59:27 <bowlofeggs> i would think someone doing automated updates could also automate configuring dnf to do the --best too though, if they wanted that
16:59:49 <bowlofeggs> so i guess the question comes down to: which type of user do we want the defaults to benefit the most?
17:00:21 <ignatenkobrain> nirik: I guess so
17:00:24 <otaylor> And how much we value consistency with RHEL
17:00:30 <nirik> someone doing updates should be using dnf-automatic I would think.
17:00:31 <bowlofeggs> we don't default to doing automated updates, so doing this setting for the benefit of a thing we dont' do by default doesn't seem compelling to me
17:00:35 <contyk> otaylor: +1
17:00:40 <nirik> otaylor: yeah.
17:01:05 <contyk> we're out of time, btw
17:01:25 <contyk> I'd propose we discuss thsi in the ticket for another week
17:01:29 <bowlofeggs> contyk: +1
17:01:32 <tyll> does it make sense to defer this until Rawhide gating? Then at lesat for Fedora-only repos it would not be a problem, would it?
17:01:33 <jforbes> +1
17:01:43 <nirik> contyk: +1
17:01:43 <zbyszek> contyk: +1
17:01:45 <bowlofeggs> tyll: yeah we should be able to stop broken repos from happening
17:01:48 <tyll> contyk: +1
17:01:58 <nirik> yep. if we can't do that, the gating is not working right.
17:02:05 <bowlofeggs> tyll: but as igor said, there are 3rd party repos too ☺
17:02:34 <bowlofeggs> i don't think we need a formal vote on whether to talk in ticket for a week
17:02:34 <contyk> #info There are too many things to consider. We will discuss this in the ticket for another week.
17:02:41 <contyk> we don't
17:02:45 <tyll> bowlofeggs: yes, I am not sure if "--best" is the best behavior in the 3rd party repo case
17:02:53 <contyk> there's one more topic; should we go over?
17:03:04 <bowlofeggs> tyll: yeah i'm leaning -1 but want to talk more first :)
17:03:06 <contyk> technically we already are
17:03:11 <zbyszek> I can continue
17:03:12 <bowlofeggs> contyk: i would say no
17:03:17 <bowlofeggs> but i can continue
17:03:21 <bowlofeggs> i just think it's good to time box
17:03:22 <contyk> ;)
17:03:24 <bowlofeggs> we're already at 2 hours
17:03:30 <contyk> it might be short
17:03:35 <contyk> #topic #2084 "Fedora packaging service" kickoff
17:03:38 <contyk> .fesco 2084
17:03:40 <contyk> https://pagure.io/fesco/issue/2084
17:03:40 <zodbot> contyk: Issue #2084: "Fedora packaging service" & packit ask - fesco - Pagure.io - https://pagure.io/fesco/issue/2084
17:03:50 <ttomecek> o/
17:04:25 <contyk> okay, this wouldn't be quick
17:04:38 <ttomecek> yes, let's reschedule?
17:04:44 <contyk> yeah
17:04:46 <nirik> so, should this move to the list for wider input?
17:04:47 <bowlofeggs> zbyszek: i'm not hugely invested in having this be a service, just thought it was worth mentioning the-new-hotness plans
17:04:59 <bowlofeggs> haha yeah this one is a complex topic
17:05:29 <contyk> ttomecek: would you post to devel if you haven't already?
17:05:35 <ttomecek> I will
17:05:46 * contyk nods
17:05:54 <jforbes> thanks
17:06:07 <zbyszek> I need to figure out some things too... I tried rebase-helper today, to do a trivial systemd update, and after 2h of 100% I had to kill it
17:06:09 <contyk> #info ttomecek will share this on devel@, FESCo will continue discussing in the ticket and will revisit in a week
17:06:15 <contyk> alright!
17:06:16 <nirik> I think it sounds pretty cool... automation is good.
17:06:19 <bowlofeggs> cool
17:06:22 <contyk> #topic Next week's chair
17:06:34 <zbyszek> I can
17:06:48 <contyk> that was quick, thank you
17:06:57 <contyk> #action zbyszek will chair next meeting
17:07:01 <contyk> #topic Open Floor
17:07:13 <ttomecek> zbyszek, yes, that's why I tried to point out there are multiple workflows we intend to cover, I also really like last Igor's comment
17:07:24 * contyk will give it a minute
17:07:42 * ttomecek is not trying to open any discussion :D
17:08:09 <bowlofeggs> haha
17:08:11 <contyk> ;)
17:08:15 <contyk> ok, let's close this
17:08:16 <bowlofeggs> man this was a long one
17:08:18 <contyk> #endmeeting