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