15:00:14 <jforbes> #startmeeting FESCO (2019-02-11)
15:00:14 <zodbot> Meeting started Mon Feb 11 15:00:14 2019 UTC.
15:00:14 <zodbot> This meeting is logged and archived in a public location.
15:00:14 <zodbot> The chair is jforbes. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:14 <zodbot> The meeting name has been set to 'fesco_(2019-02-11)'
15:00:14 <jforbes> #meetingname fesco
15:00:14 <zodbot> The meeting name has been set to 'fesco'
15:00:14 <jforbes> #chair nirik, bowlofeggs, jforbes, zbyszek, tyll, sgallagh, contyk, mhroncok, otaylor
15:00:14 <zodbot> Current chairs: bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh tyll zbyszek
15:00:14 <jforbes> #topic init process
15:00:28 <mhroncok> hey!
15:00:30 <bowlofeggs> .hello2
15:00:31 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:00:38 <contyk> .hello psabata
15:00:39 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:44 * contyk is around this time
15:00:45 <sgallagh> .hello2
15:00:46 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:06 <mdomonko> hey guys!
15:01:18 <bcotton> .hello2
15:01:19 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:01:19 <jforbes> Wow, quorum in less than a minute :) Will give it a few more to see who else is around
15:01:41 <mhroncok> bowlofeggs: hi =E2=98=BA
15:01:50 <bowlofeggs> haha
15:02:06 <bowlofeggs> is that a reference to how my e-mails look on our pagure tickets? ☺
15:02:23 <contyk> is that a bowl of eggs?
15:02:36 <otaylor> .hello2
15:02:37 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:02:38 <zbyszek> .hello2
15:02:40 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:02:40 <mhroncok> wow
15:02:42 <mhroncok> hi all
15:02:50 <zbyszek> hi miro
15:03:54 <jforbes> #topic #2063 F30 Change: Ibus-typing-booster default for Indian languages
15:03:54 <jforbes> .fesco 2063
15:03:54 <jforbes> https://pagure.io/fesco/issue/2063
15:03:55 <zodbot> jforbes: Issue #2063: F30 Change: Ibus-typing-booster default for Indian languages - fesco - Pagure.io - https://pagure.io/fesco/issue/2063
15:04:25 <sgallagh> This came up in the Workstation meeting a little while ago.
15:04:39 <sgallagh> I think we should defer approval to that WG, as they're the ones who best understand the problem.
15:04:45 <sgallagh> s/defer/delegate/
15:05:08 <jforbes> I am completely fine with that
15:05:10 <zbyszek> It would be nice to get input from actual Indian locale users
15:05:18 <mhroncok> sgallagh: makes sense
15:05:37 <contyk> yeah, let's defer it to them
15:05:39 <sgallagh> zbyszek: That also came up in the WG meeting, that's their next step
15:05:43 <mhroncok> zbyszek: and thta makes sense as well, but I guess Workstation WG can get that easily than we do... ?
15:05:54 <zbyszek> As easily, yeah
15:05:55 * sgallagh was lurking, but agreed with what otaylor said there.
15:06:10 <jforbes> proposal: Defer to the Workstation WG as they have the best understanding of the problem
15:06:15 <mhroncok> +1
15:06:16 <zbyszek> I too think that defererring to WG is fine
15:06:19 <zbyszek> +1
15:06:20 <sgallagh> s/defer/delegate/
15:06:22 <sgallagh> but +1
15:06:29 <contyk> +1
15:06:32 <zbyszek> Yeah, delegate
15:06:37 <jforbes> okay
15:06:38 <otaylor> +1
15:06:56 <bowlofeggs> +1 to delegate to WG
15:07:13 <bcotton> can we give the Workstation WG a deadline to decide as part of that delegation?
15:07:51 <bowlofeggs> well since they are volunteers, i'm not sure we could enforce a deadline
15:07:56 <mhroncok> bcotton: we can try
15:08:00 <bowlofeggs> we can ask them to do it soon ☺
15:08:01 <mhroncok> but what bowlofeggs said
15:08:06 <jforbes> #agreed Ibus-typing-booster default for Indian language is delegated to the Workstation WG as they have the best understanding of the problem (+7,0,-0)
15:08:13 <bcotton> well the deadline is "if you don't approve it by X, then it's rejected for F30"
15:08:26 <bowlofeggs> ah yeah i suppose we could do that
15:08:30 <bcotton> (alternately: "if you don't reject it by X, then it's accepted for F30")
15:08:34 <bowlofeggs> bcotton: do you have a suggested date?
15:08:51 <mhroncok> (no for the alternative deadline form)
15:09:04 <bcotton> bowlofeggs: i'd say 1 week if we tell them today
15:09:18 <bcotton> they meet earlier on monday, so by next week's fesco meeting we should know their answer
15:09:34 <mhroncok> unless they skip a meeting for whatever reason
15:09:38 <bowlofeggs> that sounds ok to me, though what if they don't get quorum?
15:09:48 <bcotton> they can vote asynch during the week
15:10:07 <bowlofeggs> ok
15:10:24 <mhroncok> +1 to a week if the default is to pospone to f31
15:10:25 <jforbes> That might be hard if they are also trying to get fedback from Indian locale users. otaylor opinion on the deadline?
15:10:33 <bcotton> we can go with 2 weeks, but that would put the decision deadline _after_ the change checkpoint
15:10:39 <bowlofeggs> oh yeah
15:11:07 <otaylor> I'll coordinate something, I don't know if it will come to a formal vote, compared to working with the proposer
15:11:37 <otaylor> We can say one week, and I'll chase WG members offline if necessary (don't think it will be)
15:11:44 <jforbes> Sounds good.  You will take the issue from here to the WG then as well?
15:11:46 <bowlofeggs> why don't we just say that the WG has to make a decision by the change checkpoint?
15:12:12 <bowlofeggs> i.e., if we get to that checkpoint and it's not ready, it waits till F31
15:12:14 <tyll_> .hello till
15:12:15 <zodbot> tyll_: till 'Till Maas' <opensource@till.name>
15:12:16 <zbyszek> bowlofeggs: "by" is too late, it needs implementation time
15:12:28 <bowlofeggs> zbyszek: i mean, including approval and implementation
15:12:37 <bowlofeggs> if both can't happen by then, for whatever reason, it needs to wait
15:12:44 <jforbes> #action otaylor will take the issue to the Workstation WG
15:12:45 <bcotton> bowlofeggs wfm
15:13:06 <mhroncok> bowlofeggs: let's say 1 week, but in fact do it as bowlofeggs says
15:13:20 <bowlofeggs> either way is fine with me
15:13:27 <zbyszek> I think we can move on. otaylor knows the schedule.
15:13:32 <mhroncok> ok
15:13:47 <jforbes> #topic #2068 Opt-out from branching for rust packages
15:13:47 <jforbes> .fesco 2068
15:13:47 <jforbes> https://pagure.io/fesco/issue/2068
15:13:49 <zodbot> jforbes: Issue #2068: Opt-out from branching for rust packages - fesco - Pagure.io - https://pagure.io/fesco/issue/2068
15:13:57 <mhroncok> there still seem to be confusion
15:14:21 <bowlofeggs> yeah i find this one a bit confusing too
15:14:24 <mhroncok> I'm +1 regardless, better not to have branches than creating false asumtions about the packages in those branches
15:14:47 * tyll agrees with mhroncok
15:14:48 <bowlofeggs> part of my confusion is that i still feel like i don't quite grok how modularity works, to be honest
15:15:00 <jforbes> Do we even have a process for not branching specific bits?
15:15:09 <mhroncok> I don't think we have
15:15:10 <bowlofeggs> i don't mind people using branches the way they want to though
15:15:24 <bowlofeggs> jforbes: i doubt it, but don't know
15:15:25 <mhroncok> however we can approve the thing and ignatenkobrain will work with releng
15:15:32 <contyk> it feels weird to keep this in the distro just to query the metadata
15:15:36 <contyk> there must be a better way
15:16:07 <tyll> contyk: also when we continue with a better solution, not branching is still a good option now
15:16:14 <mhroncok> I agree, however not approving this would not change that
15:16:16 <ignatenkobrain> .hello2
15:16:17 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:16:34 <contyk> oh I'm not disagreeing
15:16:36 <ignatenkobrain> about keeping in a distro: we would like to move it outside to MBO
15:16:39 * zbyszek agrees with mhroncok too
15:16:39 <ignatenkobrain> MBI
15:16:58 <ignatenkobrain> but we don't have resources (I mean computers) for MBI yet
15:17:03 <ignatenkobrain> so I'd like to have it in rawhide
15:17:08 <ignatenkobrain> and yes, I will do work with releng
15:17:10 * contyk still hasn't seen the MBI proposal/thing
15:17:22 <otaylor> ignatenkobrain: is there some talk, or detailed writeup about how you are handling rust? I'm really confused by the whole thing
15:17:25 <ignatenkobrain> contyk: you should ;)
15:17:47 <contyk> ignatenkobrain: yes, I should many things, but days are too short
15:17:53 <ignatenkobrain> otaylor: do you have more specific questions? we handle them in rawhide as a normal packages and then apps depend on -devel packages
15:18:07 <ignatenkobrain> but all those -devel packages are basically outdated in released Fedora
15:18:09 <ignatenkobrain> and we want to avoid it
15:18:11 <mhroncok> contyk: and nights are dark and full of terrors
15:18:35 <tyll> ignatenkobrain: I guess the big question is why the packages need to be in Rawhide if they should be only used in module building
15:18:36 <ignatenkobrain> what we do now with rust apps, we just build all crates as part of building a module with application and then just filtering them out
15:18:37 <jforbes> Rust just seems to have been a constant stream of "how do I make this fit?"
15:18:39 <otaylor> ignatenkobrain: I guess I don't understtand why you want to do things in rawhide *and* in modules
15:19:13 <ignatenkobrain> tyll: they don't need to be in rawhide, but they need to be somewhere (built) in order to generate modulemds for apps
15:19:27 <ignatenkobrain> otaylor: because I need repo where they are built in order to query metadata
15:19:40 <contyk> so since we don't have a mechanism for this, what exactly happens if we approve it?
15:19:54 <contyk> a ticket for releng to update their branching scripts?
15:20:05 <ignatenkobrain> contyk: I'll work with mboddu to not get them branched
15:20:31 <contyk> are we aware of any other processes, docs and tools that would need to be updated?
15:20:35 <zbyszek> Shouldn't be to hard too apply some regexp. Fortunately all rust crates are named consistently.
15:20:37 <ignatenkobrain> I would like to avoid doing 500+ `fedpkg retire` right after branching
15:20:55 <ignatenkobrain> jforbes: it is not only about rust
15:20:59 <ignatenkobrain> it is also about golang and java
15:21:25 <mhroncok> contyk: I guess we'll find out during thich branching about those
15:21:27 * mboddu guessing this is about skipping branching for some packages
15:21:31 <tyll> can't the module build process be improved to not require ursine builds before doing the actual module builds?
15:21:35 <mhroncok> mboddu: yes
15:21:52 <ignatenkobrain> tyll: they don't require ursine builds, but something needs to generate modulemd
15:21:59 <ignatenkobrain> and in order to generate modulemd you need to know dependencies
15:22:06 <ignatenkobrain> and in order to know dependencies, you need packages built somewhere
15:22:24 <tyll> how do you build the pkgs initiall if you do not know the dependencies?
15:22:44 * otaylor understands the use case, since he has complicated modulemd generation scripts for flatpaks that rely on the components being in ursine fedora as well, but it doesn't feel like a sustainable way of doing things
15:22:49 <mboddu> ignatenkobrain: Are crates also going to follow the same way as the apps?
15:23:00 <jforbes> ignatenkobrain: Oh, I understand. Rust was just the pioneer on some of these things as it came in. I think there is an overriding issue of "there are things that don't fit into the Fedora work flow, but need to be accommodated"
15:23:19 <jforbes> At some point, we need to create a real work flow to accommodate those things
15:23:24 <ignatenkobrain> otaylor: did you read MBI proposal?
15:23:33 <ignatenkobrain> tyll: incrementally
15:23:45 <ignatenkobrain> they are built in some order and then it is just about adding new ones
15:23:47 <ignatenkobrain> without rebootstrapping them
15:24:03 <ignatenkobrain> so rawhide is the repo which contains 500+ crates now
15:24:19 <ignatenkobrain> jforbes: mizdebsk already orphaned hundreds of his java packages
15:24:19 <otaylor> ignatenkobrain: I scanned it, it sounded, honestly, *very complex* - I think we have to worry about creating a Fedora that isn't approachable to outsiders
15:24:39 <contyk> ignatenkobrain: could you generate the buildorder based on upstream crate metadata?
15:24:50 <mhroncok> otaylor++
15:24:50 <zodbot> mhroncok: Karma for otaylor changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:24:51 <ignatenkobrain> contyk: no
15:25:11 <ignatenkobrain> we have some patches in crates to bump deps to newer versions, to relax their deps and so on
15:25:28 <ignatenkobrain> eventually it will be in upstream, but some upstreams are dead
15:25:51 <ignatenkobrain> otaylor: I agree, that's why we want to experiment with it and if it works out, then we can make it easier for fedora contributors to use it
15:26:05 <ignatenkobrain> and you could do it for flatpak, I can do it for rust, mizdebsk can do it for java
15:26:13 <contyk> I just agree with jforbes that we should have some "real workflow" for this, not building it somewhere somehow first, then scan it, then generate the real build recipe...
15:26:17 <ignatenkobrain> another option could be if releng can give us special side-tags
15:26:26 <ignatenkobrain> which would last long and generate its own repos
15:26:29 <ignatenkobrain> mboddu: ^
15:27:20 <ignatenkobrain> contyk: I also agree with you, but in the meantime I just don't want to end up having f30 with bunch of outdated packages ;)
15:27:47 <jforbes> And that may be the answer, but I think we still need to make a decision on this one way or the other. Branch point is 8 days away, and there is some releng work required, so I don't think we can punt on this one
15:28:11 <ignatenkobrain> doing that in Fedora's koji might require updating it and using dist-repos because it's only thing which can generate separate source repos
15:28:24 <tyll> IMHO there is not reason to branch the pkgs, regardless on how we move forward
15:28:47 <zbyszek> FWIW, I think we should approve the ticket as is, and get input from other groups (mizdebsk for java, etc), if they want to be exluded too.
15:28:54 <mboddu> ignatenkobrain: How many side tags you think you would need?
15:28:55 <otaylor> If the rust sig has a way of working, I don't see getting in the way of what they have working and requiring branches to be created and removed
15:29:02 <ignatenkobrain> zbyszek: he just orphaned his packages ;)
15:29:10 <mizdebsk> java packages shouldn't be excluded from branching or mass-rebuild
15:29:20 <mizdebsk> these packages should be retired instead.
15:29:24 <otaylor> Even if we don't think the approach is a good long term approach
15:29:33 <ignatenkobrain> mboddu: dunno, 3-4? for now
15:29:42 <mhroncok> mizdebsk: and if we retire them, things will break horribly
15:29:44 <bowlofeggs> +1 to allowing non-branching (though i don't know who will do the work, but imo we don't need to know that to approve it)
15:30:05 * nirik is here now after wireless network doom.
15:30:08 <mhroncok> the ticket is def acto approved BTW
15:30:09 <ignatenkobrain> bowlofeggs: as I said, I will work with Mohan to get this done
15:30:14 <jforbes> Right, so I propose we vote on the actual request, which is to allow rust to opt out of branching for F30.  Once that vote is done, I would like to see a new issue created with how we create a work flow more suitable
15:30:23 <mizdebsk> using ursa-major would allow for retirement, but this committee didn't want it implemented
15:30:38 <mhroncok> mizdebsk: becasue the workflow is not ready for packagers
15:30:46 <bowlofeggs> nirik: admiral adama told you not to network the ship - did the cylons get through all 24 of your firewalls?
15:31:00 <zbyszek> +1 from me to approve the ticket
15:31:01 <mhroncok> mizdebsk: braking everything to prove a point won't change that
15:31:08 * mhroncok already voted, +1
15:31:33 <otaylor> +1 on approving the non-branching
15:31:58 * mizdebsk is just answering to zbyszek's question
15:32:07 <jforbes> nirik: is there a lot of work involved in skipping branching for a list of packages?
15:32:10 * nirik is ok with the not branching part
15:32:31 <zbyszek> What about golang?
15:32:39 <nirik> mboddu would know more, I've not done that...
15:33:00 <ignatenkobrain> zbyszek: I didn't propose anything to Golang SIG yet, but essentially they are having same problems
15:33:00 <mboddu> jforbes: Not so much work depending on how we approach it
15:33:19 <ignatenkobrain> so this ticket is just about rust packages
15:33:28 <contyk> ftr, also +1 to non-branching
15:33:44 <jforbes> +1 here as well if it isn't too much work for releng
15:34:06 <mboddu> ignatenkobrain: So, crates and apps both will be excluded or just the apps?
15:34:10 <zbyszek> mizdebsk: I read your mail now :(
15:34:14 <otaylor> I don't want to *encourage* adoption of this approach for all similar situations in Fedora - lets see how it goes for rust, and if we can figure out something more appropriate.
15:34:29 <mhroncok> jforbes: I don't think we should be concerned if whether this is possible or how much work it is
15:34:32 <ignatenkobrain> mboddu: apps do not require anything special, they already have been moved to "latest" branch.
15:34:42 <jforbes> sgallagh ?
15:34:46 <mhroncok> jforbes: we just allow it, we don't ensure it happens
15:34:49 <ignatenkobrain> mboddu: I can give you list of packages or a way to do it
15:34:51 <sgallagh> Sorry, I'm distracted today.
15:35:01 <mboddu> ignatenkobrain: Okay, that works
15:35:04 <sgallagh> I'm +1
15:35:14 <otaylor> I think the general idea "we want a bunch of new packages in a module, we want them to be built in the right order, we don't want to have manually maintained buildorder integers" is very reasonable, and shouldn't require huge hoops
15:35:30 <jforbes> mhroncok: Well, I am concerned because if it is a ton of work, writing a script to mass orphan is not too much work. But mboddu said it wasn't so I am okay with that
15:36:39 <mhroncok> jforbes: I understand the concern. I just wanted to point out that we vote on "allow", not "enforce releng to do it"
15:37:01 <mhroncok> not important now anyway. this seems approved
15:37:01 <mboddu> jforbes: If I have a list of packages, then I will skip them from branching, or probably store it in something like pdc and use that info
15:37:04 <ignatenkobrain> mboddu: `sudo dnf --repo=koji-rawhide repoquery --whatprovides 'crate(*)' --source | sed -r -e 's|-[^-]+-[^-]+[^-]+$||'`
15:37:23 <mhroncok> ignatenkobrain: can you solve the details not in this meeting please?
15:37:25 <jforbes> #agreed Opt-out from branching for rust packages is approved (+6,0,-0)
15:38:06 <mboddu> ignatenkobrain: +1
15:38:28 <mhroncok> ignatenkobrain, mboddu: thank you both for providing more info here
15:38:31 <jforbes> mhroncok: Correct, but why would we allow a lot of work to be put on releng when another solution exists? In my mind, it was worth considering for the approval.
15:38:49 <jforbes> #topic #2070 F30 Change: Bash 5.0
15:38:50 <jforbes> .fesco 2070
15:38:50 <jforbes> https://pagure.io/fesco/issue/2070
15:38:51 <zodbot> jforbes: Issue #2070: F30 Change: Bash 5.0 - fesco - Pagure.io - https://pagure.io/fesco/issue/2070
15:39:20 * nirik was +1 in ticket
15:39:28 <tyll> +1
15:39:28 * zbyszek was +1 too
15:39:43 <mhroncok> I guess +1 if we cahnge it to systemwide
15:40:06 <mhroncok> clearly, everything depends on this
15:40:08 <ignatenkobrain> Just FYI, openSUSE Leapp has 5.0 already =)
15:40:22 <sgallagh> I'm +1
15:40:23 <ignatenkobrain> or tumbleweed or whatever name is
15:40:30 <otaylor> +1 - though would recommend reverting without thinking twice if we hit problems
15:40:39 <mhroncok> ignatenkobrain: oh now, one of the the Defora foundations, being Second :D
15:40:49 <bowlofeggs> i feel conflicted on this one
15:41:05 <ignatenkobrain> mhroncok: yeah, we are Second here =(
15:41:08 <mhroncok> *Fedora
15:41:16 <bowlofeggs> i guess it is easy to revert
15:41:22 <contyk> +1; if there are problems, we need to fix them
15:41:42 <jforbes> Yes, issues being, it is systemwide, and after that deadline, but nirik made a strong point there. People will expect it
15:41:46 <bowlofeggs> due to it being easy to revert, i'll be +1
15:42:00 <jforbes> +1 here, revert is easy
15:42:18 <nirik> yeah, revert if it causes issues that can't be quickly fixed.
15:42:43 * wa1em lurks
15:42:53 <jforbes> #agreed F30 Change: Bash 5.0 is approved (+7,0,-0)
15:43:08 <zbyszek> .fasinfo wa1em
15:43:09 <zodbot> zbyszek: User "wa1em" doesn't exist
15:43:18 <jforbes> #topic #2074 F30 Change: Retire Yum 3
15:43:18 <jforbes> .fesco 2074
15:43:18 <jforbes> https://pagure.io/fesco/issue/2074
15:43:19 <zodbot> jforbes: Issue #2074: F30 Change: Retire Yum 3 - fesco - Pagure.io - https://pagure.io/fesco/issue/2074
15:43:21 <wa1em> jforbes,  linuxmodder is the fasid
15:43:28 <tyll> +1
15:43:28 <mhroncok> jforbes: I have a proposal about bash
15:43:57 <jforbes> mhroncok: okay
15:43:57 <zbyszek> .fasinfo linuxmodder
15:43:58 <zodbot> zbyszek: User: linuxmodder, Name: Corey W Sheldon, email: sheldon.corey@gmail.com, Creation: 2016-04-24, IRC Nick: wa1em, Timezone: US/Eastern, Locale: en, GPG key ID: 0D4C51BA672FCF5C C2B852053E58CCEA, Status: active
15:44:01 <zodbot> zbyszek: Approved Groups: ambassadors fi-apprentice hosted-content fedorabugs respins-sig qa fedora-hams @fedora-join @freemedia cla_done cla_fpca
15:44:18 <mhroncok> proposal: change the category of the Bash change to systemwide, for better exposure
15:44:18 <bowlofeggs> i'm not sure i see the urgency on this one
15:44:48 <bcotton> mhroncok: i dont think that really matters after the fact
15:44:50 <zbyszek> mhroncok: Does it really matter? All changes are listed on the same page of release notes.
15:44:53 <bowlofeggs> i get that removing things is the only way to get people to act, but why not just remove it after branching and make it F31?
15:44:54 <contyk> I don't see it either; it was proposed for f28 as well, I think
15:45:03 <nirik> I am not too happy with f30 at this late date.
15:45:07 <mhroncok> I wasn't sure it matters until recently
15:45:12 * mhroncok finds link
15:45:42 <nirik> since I am sure there's going to be something we didn't think about, so it will be more work for releng/infra... and we are already well along on f30
15:45:45 <mhroncok> https://bugzilla.redhat.com/show_bug.cgi?id=1626684#c11
15:46:28 * mhroncok is not sure what to discuss first
15:46:35 <bowlofeggs> proposal: defer yum 3 retirement to F31, and fesco encourages removal immediately after f30 branching
15:46:37 <contyk> I totally see it as a system wide change
15:47:01 <mdomonko> please note that python-urlgrabber has been removed from the proposal, reducing the number of dependants that need to be ported
15:47:03 * nirik waits for bz
15:47:11 <zbyszek> OK, if somebody proposes "upgrading" to system-wide, I'd be happy to vote for it
15:47:17 <bcotton> i agree with bowlofeggs' proposal
15:47:32 <mhroncok> does bowlofeggs proposal work for mdomonko?
15:47:33 <nirik> but of course in f31 we are looking at dropping all python2 things, right?
15:47:58 <mhroncok> I'm afraid that if we defer this any further, dnf team will just orphan it and be done with proposals for good :(
15:48:07 <mhroncok> nirik: I don't think so
15:48:11 <mdomonko> yeah, in case of pushing this to F31, we would put python-urlgrabber back (meaning it would get dropped from F31)
15:48:47 <nirik> I think we should definitely have a time... but I think f31 makes more sense now... and could be done right after branching
15:48:55 <zbyszek> FWIW, I think we should with the change as proposed in F30, and if things go truly south, we can always unretire
15:48:56 <nirik> that gives us a nice long runway to fix it before f31
15:49:00 <mdomonko> so the reason we proposed this for F30 initially was to encourage the dependants to act :)
15:49:12 <mdomonko> zbyszek: +1
15:49:14 <nirik> they do seem to be now...
15:49:21 <nirik> (there is a koji PR now at least)
15:49:23 <contyk> +1 to bowlofeggs, +0 to dropping it in f30
15:49:24 <zbyszek> nirik: I'm afraid that with the python2 stuff being dropped in F31, there's be rush anyway
15:49:36 <bowlofeggs> won't dependents also have to act if we drop it right after branching anyway?
15:49:37 <nirik> +1 bowlofeggs
15:49:54 <bowlofeggs> i'm not sure F30 is more effective at getting them to act
15:50:09 <bowlofeggs> branching is real soon
15:50:18 <jforbes> I am going to have to agree here. Branch point is 8 days away
15:50:32 <mhroncok> this is half a year of support
15:50:38 <mhroncok> not 8 days before we act
15:50:54 <mhroncok> I suppose we can do it after branching
15:51:07 <mhroncok> and let it be supported by dependent packlage maintainers for f30
15:51:25 <nirik> is there a lot of support at this point?
15:51:35 <nirik> or is it mostly just 'we won't fix that, use dnf'
15:51:37 <jforbes> mhroncok: how much active support is really involved?
15:51:58 <mhroncok> I have no idea, but we are tricking the users into thinking there is some if there is none
15:52:32 <mdomonko> nirik: it's mostly the latter, however there are occasional requests coming in to introduce bool deps support etc.
15:52:41 <zbyszek> For one, yum is currently FTBFS, since F29 apparently
15:52:53 <mdomonko> zbyszek: and yeah, things like these
15:52:55 <zbyszek> https://koji.fedoraproject.org/koji/packageinfo?packageID=21
15:53:02 <nirik> fun
15:53:05 <jforbes> mhroncok: We have an entire arch like that. I mean theoretically there is a SIG, but they haven't even had an email in almost 6 months
15:53:48 <mhroncok> yum FTBFS since f29?
15:53:59 <mhroncok> than it shall be retired by policy if it FTBFS during f30
15:54:09 <bowlofeggs> if it FTBFS i guess we do have that policy…
15:54:19 <zbyszek> It looks like it *could* be fixed, just noone seems to be looking into it
15:54:26 <zbyszek> https://bugzilla.redhat.com/show_bug.cgi?id=1606775
15:54:47 <nirik> anyhow, do any of the proposals have enough votes to pass?
15:54:51 <mdomonko> zbyszek: and that's the problem. the DNF team is busy with a milion other things than to fix-up something that's already deprecated anyway
15:55:09 <mdomonko> zbyszek: though it's probably an easy fix in this case
15:55:26 <mhroncok> proposal: ...
15:55:39 <mhroncok> we do this in f30. contingency is to unretire
15:55:56 <zbyszek> mhroncok: +1
15:56:03 <mdomonko> mhroncok: +1
15:56:23 <otaylor> mhroncok: +1
15:56:31 <zbyszek> nirik: I think we should vote F30 first (mhroncok's proposal), and if that fails, F31
15:56:38 <nirik> mhroncok: -1
15:56:44 <nirik> sure
15:56:47 <tyll> mhroncok: +1
15:56:48 <contyk> I abstain
15:56:52 <otaylor> (yum3 feels like zombie code at this point, and I think we're not actually doing anybody a favor by keeping it stumbling around)
15:56:57 <bowlofeggs> does it fail to install, or just fail to build?
15:57:08 <nirik> bowlofeggs: build
15:57:34 <mdomonko> bowlofeggs: just tried it myself with "fedpkg mockbuild" and I got something like "/bin/sh: python: command not found"
15:57:50 <mdomonko> bowlofeggs: but who knows
15:58:11 <otaylor> mdomonko: that was the FTBS logs, I'm sure it's not a hard fix, but if nobody *has* fixed it in 6 months, that says something in itself
15:58:12 <nirik> that is likely easyfix
15:58:29 <jforbes> otaylor: if it is zombie code that works though, leaving as is for F30 with a clear removal date of f31 branch seems like the safer choice, with no actual extra workload on the dnf team
15:58:30 <bowlofeggs> yeah that's just that you need to explicitly use /usr/bin/python2 instead of /usr/bin/python
15:58:30 <mhroncok> the easyfix is to retire the package
15:58:39 <jforbes> mhroncok: -1
15:59:05 <zbyszek> I just checked, and it installs both fine in F29 and rawhide
15:59:15 <bowlofeggs> i am intrigued by the argument that the FTBFS policy would remove it, however
15:59:39 <otaylor> jforbes: the question is whether someone using yum3 on Fedora is going to spend a week with weird problems due to lack of binary dep support, etc, before being told "oh, that's dead"
16:00:20 <bowlofeggs> we didn't actually apply all teh steps fo the FTBFS policy here though
16:00:25 <bowlofeggs> https://fedoraproject.org/wiki/Fails_to_build_from_source
16:00:25 <nirik> I guess the main headaches will come right after f30 release.
16:00:40 <bowlofeggs> like, we didn't do steps 3 and 4
16:00:43 <mhroncok> nirik: so we unretire
16:00:59 <mhroncok> if we move to f31, the main headaches will come right after f31 release
16:01:20 <nirik> sure... but that gives time for the koji PR to land, get in a release, issues with it fixed...
16:01:22 <otaylor> jforbes: I think leaving around is only the safer choice if there is some set of people who are using the yum3 code (interactively, or as part of a build process), that can keep on using it, and it actually works for them. It's possible that mock+epel is such a case, I don't know.
16:01:35 <nirik> so we can calmly upgrade to the new version
16:01:51 <nirik> otaylor: it is. we do that currently.
16:02:09 <mdomonko> hasn't this been the case forever? :) like, we have been saying yum3 is deprecated and please don't use it/ port your code
16:02:15 <mdomonko> since F22 or so
16:02:20 <mdomonko> and here we are :)
16:02:31 <mhroncok> and here we'll be in 6 months
16:02:34 <nirik> proposal: give yum ownership to me... move change to f31
16:02:35 <mdomonko> right
16:02:35 <bowlofeggs> right, but doing it for F31 immediately after branching is still effective
16:02:43 <bowlofeggs> nirik: +1
16:02:53 <jforbes> mdomonko: No, we wouldn't be having this discussion if it were removed at f29 branching
16:03:01 * nirik is happy to just tell people to stop using it, and I can fix the FTBFS and the dnf people don't need to worry about it
16:03:12 <nirik> is that acceptable?
16:03:18 <mhroncok> +1 to nirik iff we remove it right after branching
16:03:29 <zbyszek> +1 the same
16:03:32 <mdomonko> jforbes: yeah, this re-proposal came in late, that's for sure :/
16:03:37 <mdomonko> nirik: acceptable for me
16:03:41 <nirik> in fact the change owners can remove it still... thats fine.
16:03:42 <jforbes> The problem is putting in a system-wide change this late after the deadline
16:04:05 <contyk> yep
16:04:07 <bowlofeggs> yeah if this had come in a few weeks ago i'd +1 it
16:04:18 <mdomonko> jforbes: I think it depends on whether we all agree it's a system-wide one
16:04:40 <bcotton> it does seem to be system-wide
16:04:44 <jforbes> I think the fact that it has a direct impact on koji pretty much makes it one
16:04:56 <mhroncok> mdomonko: as long as infra uses it, it unfortunately still is system wide
16:05:06 <mdomonko> ok, makes sense
16:05:22 <mhroncok> can we vote on nirik's proposal?
16:05:23 <otaylor> +1 to nirik's proposal
16:05:34 <jforbes> +1 nirik
16:05:36 <zbyszek> +1 nirik
16:06:14 <contyk> +1
16:06:23 <tyll> +1
16:06:25 * bowlofeggs is still +1
16:06:36 <tyll> should nirik just become the new maintainer of yum then?
16:06:39 <contyk> nirik should own everything anyway
16:06:45 <mhroncok> :D
16:06:51 <nirik> ha.
16:07:05 <jforbes> #agreed Retire Yum 3 is deferred to F31, and should be removed immediately after branching (+6,0,-0)
16:07:13 <sgallagh> +1
16:07:18 <nirik> I'm happy to deal with bugs... if dnf folks want me to be default assignee I can... or just cc me
16:07:20 <jforbes> #undo
16:07:20 <zodbot> Removing item from minutes: AGREED by jforbes at 16:07:05 : Retire Yum 3 is deferred to F31, and should be removed immediately after branching (+6,0,-0)
16:07:21 <sgallagh> Sorry, was trying to find the proposal
16:07:29 <mdomonko> cool with me :) thanks guys
16:07:33 <jforbes> #agreed Retire Yum 3 is deferred to F31, and should be removed immediately after branching (+7,0,-0)
16:08:10 <nirik> mdomonko: feel free to add me to the packages. Do you want to still remove after branching, or want me to?
16:08:28 <jforbes> mhroncok: did you want to swing back to bash, or do you feel that is unnecessary?
16:08:51 <mhroncok> jforbes: I stillwant the bash change (and this one as well) to be recategorized as system wide changes
16:08:57 <mdomonko> nirik: yup, let's take this to a private msg
16:09:09 <nirik> mdomonko: sure.
16:09:26 <mhroncok> most of us think it doesn't matter, so we should be fine doing it ;)
16:09:47 <jforbes> proposal: bash 5.0 and yum3 to be recategorized as system-wide changes
16:09:53 <zbyszek> jforbes: +1
16:09:56 <mhroncok> +1
16:09:57 <otaylor> +1
16:09:59 <contyk> +1
16:10:02 <tyll> +1
16:10:16 <jforbes> (note, this doesn't change their approval votes)
16:10:30 <nirik> +1
16:10:40 <jforbes> +1 from me as well
16:10:58 <mhroncok> thanks
16:11:00 <jforbes> sgallagh bowlofeggs
16:11:01 <zbyszek> sgallagh?
16:11:10 <sgallagh> +1
16:11:32 <bowlofeggs> +1
16:12:25 <jforbes> #agreed bash 5.0 and yum3 to be recategorized as system-wide changes (+8,0,-0)
16:12:38 <mhroncok> 9?
16:13:01 <jforbes> #topic Next week's chair
16:13:38 <contyk> I should be free
16:13:57 * zbyszek might not make it, not sure yet
16:14:06 <jforbes> #action contyk will chair next meeting
16:14:09 <jforbes> Thanks contyk
16:14:21 * mhroncok will not make it, not in time at least
16:14:26 <jforbes> #topic Open Floor
16:14:43 <mhroncok> is the provenpackager policy confusing just for me?
16:15:06 <zbyszek> mhroncok: in what way?
16:15:24 <mhroncok> https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_becoming_provenpackager
16:15:46 <sgallagh> I will not be around next week.
16:15:50 <bcotton> jforbes: i have an item for open floor
16:16:05 <mhroncok> fesco ticket, sponsors list "for packager group"
16:16:06 <zbyszek> Ah, part 2 is misleading indeed.
16:16:11 <mhroncok> who votes? and where?
16:16:41 <zbyszek> Proposal: drop point 2 from "Becoming provenpackager"
16:16:43 <contyk> ah, we had those tickets both in our and the sponsors' queues
16:17:00 <jforbes> That should probably stand to be clarified. Anyone want to take that?
16:17:14 <nirik> well, I typically did that...
16:17:24 <nirik> perhaps I have fallen down on the job lately?
16:17:37 <nirik> oh, I see, wording is bad
16:17:52 <mhroncok> zbyszek: that doesn't help entirely on its own
16:18:09 <contyk> it's still unclear whether it's fesco or the sponsors who's voting
16:18:09 <mhroncok> I don't knwo if fesco, sponsors, provenpackagers or any packagers vote
16:18:11 <nirik> "A FESCo member will send an e-mail to the packager sponsors to review the application."
16:18:20 <jforbes> nirik: Yeah, I don't think you missed anything that I am aware of, I just think the page needs to be clarified
16:18:22 <nirik> fesco votes
16:18:29 <nirik> sponsors provide feedback
16:18:46 <zbyszek> Well, if we remove that, than it's pretty clear that that people vote in the fesco ticket, according to the normal fesco rules.
16:18:50 <nirik> well, sponsors "vote" then if there's -1's fesco does
16:18:56 <jforbes> contyk: sponsors can still provide negative feedback
16:19:14 <contyk> I'm just saying it's not clear from the current wording :)
16:19:16 <nirik> the idea was that non controversial candidates are just approved by sponsors
16:19:20 <mhroncok> I donẗ think everybody even agrees on what's supposed to happen
16:19:30 <nirik> and only controversal people then go to a fesco vode
16:19:32 <nirik> vote
16:19:32 <zbyszek> Hmm, yeah, that's confusing indeed.
16:20:02 * nirik agrees the wording is poor...
16:20:24 <mhroncok> let me summarize
16:20:34 <jforbes> To put it more simply, anyone can -1 in the ticket (sponsors or FESCo members) and by doing so, to goes to FESCo for a full vote
16:21:01 <mhroncok> 1. fesco ticket is opened 2. sponsors are notified 3. sponsors vote 4. if certain conditions are met, fesco votes
16:21:09 <nirik> yeah
16:21:16 <sgallagh> mhroncok: Exactly
16:21:23 <mhroncok> I'll send a PR
16:21:44 <nirik> so, perhaps we should change it to just be 'sponsors or fesco have a week to add a -1 in the ticket, then it will go to a fesco vote'
16:21:54 <jforbes> thanks mhroncok
16:21:54 <nirik> so we avoid the +1s? or do we still want +3?
16:22:04 <mhroncok> we want pluses
16:22:06 <contyk> everyone should be a provenpackager by default ;)
16:22:15 <contyk> that would simplify so many things!
16:22:27 <jforbes> Yes, I think pluses at least tell us that *someone* has actually seen it
16:22:28 <mhroncok> I thought nirik should just own everything and no provenpackagers are needed
16:22:42 <contyk> or that
16:22:54 <zbyszek> Can we clone nirik?
16:23:00 <nirik> heh. As long as you don't mind things not being done. ;)
16:23:03 * jforbes reassigns all kernel bugs to nirik
16:23:06 <mhroncok> #action mhroncok will send a PR to docs about becoming a provenpackager
16:23:10 <zbyszek> BTW, mhroncok and bowlofeggs: I haven't forgotten about your PRs and issues about fesco-docs. I hope to get them real soon now™
16:23:20 <mhroncok> zbyszek: thanks
16:23:20 <bowlofeggs> cool ☺
16:23:35 <mhroncok> zbyszek: also, FPC removes the content from wiki, we should start doing the same
16:23:45 <mhroncok> people ignore the header and they see old content
16:23:51 <jforbes> Okay, moving on, bcotton had something as well?
16:24:00 <bcotton> yes!
16:24:07 <bcotton> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UZYPCTX4NXHMPV6YUFKVB23QFCGR5Y2Q/
16:24:24 <bcotton> Someone had an informal proposal to update mercurial to 4.9 on the devel list this morning
16:24:49 <bcotton> Strictly speaking, it's probably a self-contained change that should be submitted for f31
16:24:57 <bcotton> unstrictly speaking, it probably doesn't matter
16:25:20 <zbyszek> bcotton: is it backwards incompatible? According to the Update Policy, they are free to do it before F30
16:25:22 <bcotton> but i wanted to bring it to your attention and let FESCo decide if we should let it slide or push back as a F31 change
16:25:28 <bowlofeggs> hard to say much about it without knowing if there's an expected impact on other packages
16:25:42 <bcotton> zbyszek: that's unclear
16:25:44 <nirik> also if they plan to get them all done in one day or not.
16:26:07 <bcotton> bowlofeggs: there's a list of pacakges that are dependent, but it's not clear what the actual impact (if any) would be
16:26:38 <bowlofeggs> yeah, i don't know enough about mercurial to know if that version has incompatibilities and what not
16:26:41 <jforbes> There hasn't been enough time for anyone to provide feedback
16:26:49 <bcotton> my instinct is to say "no, this needs to be an f31 change proposal" but i don't want to do that unless FESCo has my back :-)
16:27:10 <otaylor> I think it's up to the judgment of the packager - I don't think we need to swoop in
16:27:23 <zbyszek> otaylor: agreed
16:27:53 <nirik> yeah, not sure what the impact is... some upstreams versions are very different, others not much at all... there is a soname bump I guess
16:28:27 <mhroncok> I suggest we ask the packager to work with dependent pakcage maintainers before proceeding
16:28:46 <mhroncok> but we don't require a formal change proposal
16:28:52 <zbyszek> Pfff, is there some public release notes? I can't seem to find anythign.
16:29:06 <jforbes> https://www.mercurial-scm.org/wiki/WhatsNew
16:29:21 <nirik> and if they cannot finish before branching... thats a good indicator it should be done in rawhide after branching at least initially
16:30:22 * otaylor needs to head off for a bit - later!
16:30:34 <mhroncok> otaylor: see you
16:30:37 * zbyszek needs to go to. See y'all next week.
16:31:03 <mhroncok> https://pagure.io/fesco/fesco-docs/pull-request/8
16:31:16 <mhroncok> provenpackager thing ^
16:31:22 <bcotton> okay, sounds like the consensus is: let it be. works for me
16:31:37 <jforbes> excellent
16:31:43 <jforbes> Anything else for open floor?
16:31:57 <jforbes> If not, closing in 3 minutes
16:32:29 <mhroncok> I have a question about python2 in f31
16:32:45 <mhroncok> but I will only ask this here now if more than 2 memebers are interested
16:33:24 <nirik> sure, ask away
16:33:47 <bowlofeggs> mhroncok: is it about how i should port all my packages back to python 2?
16:34:09 <mhroncok> it seems that during the yum removal discussion, people suggested that f31 will remove python2 entirely
16:34:43 <mhroncok> I am entirely sure that this is not possible at this point
16:35:25 <mhroncok> does a "python2 dependent package is whitelisted with reasons or removed" change proposal makes sense for f31?
16:36:05 <nirik> yeah... so then critical packages would be kept (if they justify themselves), but the rest dropped?
16:36:26 <bowlofeggs> i'd +1 that
16:36:30 <tyll> +1
16:36:34 <mhroncok> nirik: something like that
16:36:56 <mhroncok> we don't want to retire gimp, inkscape, chromium, mercurial...
16:37:23 <nirik> yeah. ;(
16:37:24 <jforbes> Sounds like it might be worth proposing
16:37:37 * nirik wonders if calibre would fall under this. ;)
16:37:47 <mhroncok> ipsilon
16:38:07 <mhroncok> anyway, calibre upstyream will maintain their own python2 IIRC
16:38:17 <mhroncok> thanks for your opinions on this
16:38:21 <mhroncok> that's it for now
16:38:48 <jforbes> Okay, anything else for open floor?
16:39:24 <bowlofeggs> nirik: calibre is maintaining python2 forever because it can't be that hard (right?)
16:40:08 <jforbes> #endmeeting