15:00:00 #startmeeting FESCO (2019-01-07) 15:00:01 Meeting started Mon Jan 7 15:00:00 2019 UTC. 15:00:01 This meeting is logged and archived in a public location. 15:00:01 The chair is bowlofeggs. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:01 The meeting name has been set to 'fesco_(2019-01-07)' 15:00:02 #meetingname fesco 15:00:02 The meeting name has been set to 'fesco' 15:00:04 #chair nirik, bowlofeggs, jforbes, zbyszek, tyll, sgallagh, contyk, mhroncok, otaylor 15:00:04 Current chairs: bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh tyll zbyszek 15:00:06 #topic init process 15:00:12 .hello2 15:00:13 sgallagh: sgallagh 'Stephen Gallagher' 15:00:15 .hello2 15:00:16 jforbes: jforbes 'Justin M. Forbes' 15:00:24 .hello2 15:00:26 mhroncok: Sorry, but you don't exist 15:00:35 zodbot: yeah, I know 15:00:36 .hello psabata 15:00:39 contyk: psabata 'Petr Šabata' 15:00:42 .hello2 churchyard 15:00:43 morning 15:00:43 mhroncok: Sorry, but you don't exist 15:00:50 mhroncok: you might be able to use .hello churchyard 15:00:52 (no 2) 15:00:54 .hello till 15:00:55 tyll: till 'Till Maas' 15:00:56 .hello churchyard 15:00:58 mhroncok: churchyard 'Miro Hrončok' 15:01:02 magic 15:01:09 and there are I thought you were just the product of my imagination 15:01:10 i think hello2 only works if your IRC and FAS are the same 15:01:14 haha 15:01:27 .hello2 15:01:28 otaylor: otaylor 'Owen Taylor' 15:01:59 cool we have quorum 15:02:06 let's get this party started 15:02:12 we can party like it's 2019 15:02:30 #topic #2021 F30 Change: Migrate Python-based Nautilus extensions to 15:02:31 Python 3 15:02:33 .fesco 2021y 15:02:33 bowlofeggs: Error: '2021y' is not a valid integer. 15:02:35 haha 15:02:39 .fesco 2021 15:02:41 bowlofeggs: Issue #2021: F30 Change: Migrate Python-based Nautilus extensions to Python 3 - fesco - Pagure.io - https://pagure.io/fesco/issue/2021 15:02:48 Are we reviewing OpenSSL code now? 15:02:50 :-P 15:03:34 huh a postman. give me 2 mins 15:03:48 So, am I right in the summary that what we're actually being asked is "Is it okay if functionality is dropped if we cannot migrate some of the extensions?" 15:03:51 haha 15:04:02 sgallagh: i think that's the current questio 15:04:04 n 15:04:27 and i am fine with dropping functionality for plugins that don't migrate to python 3 15:04:30 they've had 10 years 15:04:32 sgallagh: Yes, it seems that way, but the biggest risk is also to user installed extensions that can't be fixed in packages anyway 15:04:41 Definitely think that we can't block progress to python3 on some extension that was done years ago, is barely maintained or unmaintained, and we have no idea how many people are using. 15:05:00 I am under the intentionally naive assumption that maintained packages are maintained 15:05:19 jforbes: I mean upstream 15:05:19 * nirik is +1 to the change. time marches on. 15:05:29 jforbes++ 15:05:29 bcotton: Karma for jforbes changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:05:42 sorry 15:05:46 proposal: Accept the proposed change 15:05:51 +1 15:05:53 +1 15:05:53 back 15:05:56 Was advance warning given to extension maintainers about Python 3 support going away? 15:05:57 +1 15:05:59 otaylor: ^^ 15:05:59 zbyszek: we're on https://pagure.io/fesco/issue/2021 15:06:07 I voted in the ticket 15:06:12 Still +1 15:06:36 +1 (but yeah, direct mail to maintainers would be good) 15:06:36 +1 on the change 15:06:47 not sure if the wording there needs to change a bit 15:06:49 sgallagh: lots of discussion has happened on the devel list for years about python 2 going away 15:07:20 bowlofeggs: In Fedora in general, but I'm wondering if GNOME did the same on their end 15:07:23 +1 in general, but IMHO it would be nice if the extension maintainers would be provided a test command to check if their extensions are python3 ready or maybe a test build (COPR) to check it 15:07:25 sgallagh: I'm not aware of such notice - I think this change proposal could be considered to be such notice - I presume the change owners will reach out when doing rebuilds. I don't think that a multi-cycle process is necessary. 15:07:56 sgallagh: oh you mean upstream, gotcha 15:08:21 I'm mostly just hesitating because I don't like putting people into "A lack of planning on our part now constitutes an emergency on yours" situations. 15:08:35 ok i count +8 15:08:58 holy crap, do we have all 9 of us today? 15:09:11 sgallagh: the Change page is essentially 6 months of advance notice. 15:09:13 I'm a symbolic 0 vote, I guess. 15:09:20 cool 15:09:32 zbyszek: Isn't this for F30, which hits Freeze in like two months? 15:09:39 Feature Freeze, I mean 15:09:45 #agree APPROVED (+8, 1, -0) 15:10:01 Almost to the day, in fact. 15:10:15 sgallagh: I don't think it is possible for someone to maintain a python anything and not have known that python 2 was going away, and python 3 was a thing which might require some changes... For a very long time 15:10:30 the contingency plan is: Continue shipping builds of nautilus-python based on Python 2. 15:10:31 do we want to stay on this topic longer, since we have a vote? 15:10:33 jforbes: The vote is done. 15:10:41 (long agenda today) 15:10:42 I specifically said I wasn't voting against 15:10:42 I think we are good, in worst case, they will just roll it back 15:11:10 sgallagh: a fix to make an extension usable at all would be considered a fix, so it can be pushed in at any point, even after branching. 15:11:29 #topic #2027 RFC: Module lifecycles 15:11:31 .fesco 2027 15:11:32 bowlofeggs: Issue #2027: RFC: Module lifecycles - fesco - Pagure.io - https://pagure.io/fesco/issue/2027 15:11:40 It's more like 4-5 months, but I still think that's plenty of time to do soem python2→3 porting. 15:12:38 2027 is fresh, wasn't able to read it all yet 15:12:58 (at least for me I mean) 15:13:57 not super fresh but considering the holidays... 15:13:58 It seems like asamalik is looking more for feedback than a vote of approval? 15:14:16 indeed 15:14:28 in general i'm fine with the EOL being specified by date and release (which i think is the proposal), but yeah i'm not sure where that data should be stored 15:14:38 there is an FPDC project by cverna that's intended to replace PDC 15:14:47 that might be a good place to store that info 15:15:02 I think that the more that is in dist-git, and the less that is magically updated by releng via ticket, the better 15:15:07 * nirik nods. noted that in the ticket 15:15:11 I would prefer it to be stored in something that has a nice API instead of just GIT 15:15:19 git is a nice API 15:15:43 better to store it in GIT and build a different API ont op of that 15:15:44 * asamalik peeks in and waves 15:15:46 i don't have strong feelings on git vs. http API 15:15:48 rather than magic 15:15:52 I don't like the idea of storing exact dates because they're not set in stone 15:16:02 well, we already use pdc for data today... 15:16:13 So that's my concern about FPDC - it's not self service (if it's like PDC), and it's not stored "with the code" 15:16:27 yeah I'm proposing either a date or a Fedora release (or nothing) 15:16:32 I like the idea of storing the data in dist git. 15:16:34 mhroncok, you cannot do easily access the information in reverse, i.e. give me everything that is EOL with F30 with GIT but need to fetch every repo and look there 15:16:37 There is the question of "what if fedora release slips past module EOL" which I think the answer is module EOL also slips 15:16:41 this is not a nice API 15:16:48 note we can store it directly in modulemd 15:16:58 We can always build indexes on top of dist git, to provide a nice and quick API. 15:17:02 jforbes: yes 15:17:07 asamalik: The interaction of dates with fedora releases is a bit unclear to me - but I should probably comment on that in your issue 15:17:48 otaylor: i find that self-service argument compelling. i dislike how much we lost when we switched away from pkgdb 15:17:53 if we are suggesting moving everything from PDC to git and scrapping all the FPDC work, I'd really perfer a larger discussion on that... like with the people doing the fpdc work at least 15:18:09 otaylor: the idea was that you either want it to go EOL with a particular Fedora release regardless of a date, before a particular date regardless of what release that would be 15:18:14 if I have a package from a module installedd and the nodule goes EOL mid release, what actually happens? 15:18:28 where would you put in dist-git the current releases, current devel releases? 15:18:45 mhroncok: you no longer have any security coverage 15:18:47 ah, but tyll's counter argument about querying for "what is EOL with F30" is also compelling 15:18:47 mhroncok: EOL means you're not getting any more updates 15:19:26 zbyszek, we could but nobody is building these indexes... we lost them already for orphaned/retired pkgs when pkgdb was removed for example 15:19:31 asamalik: More like what happens if your module stream goes eol during a release - what is the user experience? Presumably the *default* stream of a release can't go eol. I'm not sure I have well formulated questions at this point :-) 15:19:54 that 15:20:08 otaylor: I'd like it to make it so that this can't happen 15:20:10 what if FPDC was the thing that built the index that zbyszek proposed?> 15:20:18 should we give it another week? so that everyone has enough time to read it 15:20:25 please 15:20:30 contyk: +1 15:20:39 * nirik would like to get FPDC folks to chime in. 15:20:55 nirik: can you ping them in the ticket? 15:21:02 sure. 15:21:14 nirik: I think there's some distinction between distro level metadata - and metadata about individual packages and modules - in terms of what works well. 15:21:20 (tickets aren't great for discussion tho, but I can and we can spill over to a list) 15:21:46 I don't know off the top of my head what pdc data we are currently using. 15:21:51 contyk: +1 15:22:28 nirik: If they are supportive about putting this data into the FPDC, I'd like to hear about what the maintainer experience is around updating it (and viewing it!) 15:23:11 any objections to deferring a week? 15:23:23 none here 15:23:39 yes, please defer 15:23:42 ok, let's move on 15:23:49 #topic #2028 RFC: Stream branch ownership for packages & modules 15:23:51 .fesco 2028 15:23:52 bowlofeggs: Issue #2028: RFC: Stream branch ownership for packages & modules - fesco - Pagure.io - https://pagure.io/fesco/issue/2028 15:23:59 same thing here, I guess 15:25:20 contyk: you think we should defer to next week you mean/ 15:25:32 bowlofeggs: yeah 15:25:38 I filed them together 15:25:49 would be strange if people read one and not the other :) 15:26:24 I tend to share otaylor's concerns form the ticket 15:26:51 the proposal is that you become a maintainer of the package as soon as you use it 15:27:01 there's no "time passes" between the second and the third bulletpoints 15:27:11 yeah, discoverability is not good here with current setup... but that could be of course improved. 15:27:27 yeah i think i also find otaylor's comment compelling. "explicit is better than implicit" -zen of python 15:27:41 I guess bugs and such would always be filed on the module, not on the specific rpms? 15:28:04 I think we need to allow both 15:28:09 CVE's for example are filled on rpms and the "main admin" of the component is assigned 15:28:37 or at least that is what happened this time with python-django 15:28:45 so then how do we know... 15:29:06 contyk: I think I might have a different perspective, since it's much more reasonalbe to "cherry-pick versions" for a module deployed as a flatpak, rather than one installed directly via rpms onto a system 15:29:18 nirik, how do users know that they need to file a bug for the module instead of the package? 15:29:38 So, would that main that it is the rpm admin's responsibility to make sure that module maintainers are aware of CVEs? That seems sub-optimal 15:29:44 not sure. ;) I guess they don't currently 15:30:04 * nirik wishes we had branch ownership back 15:30:07 otaylor: I understand, but I also wouldn't expect people maintaining stream branches if they're not delivering them anywhere 15:30:09 contyk: In the direct-install case, sharing a package between different modules has to be rare 15:30:34 otaylor: agreed 15:31:05 contyk: At some point, there was an idea that we'd be moving much of fedora to stream branches, as I recall 15:31:35 nirik: +1 15:31:49 I think the scenarios here are a) the package is also delivered as ursine, in which case it has a primary maintainer, b) the package is only delivered in modules, one or more, in which case there's no primary maintainer 15:32:12 and c), the package isn't delivered anywhere at the moment but could be adopted by someone; it probably isn't maintained at all 15:32:36 contyk, the package could also be retired (at least in the ursine case, not sure how this works for modules) 15:32:36 for b and c how can we tell who should deal with issues on it? 15:32:56 I wonder if we could treat case b the same as a, i.e. ask people to requests ACLs if they put the package in a stream and want to help maintain in 15:32:57 b) the package is only delivered in modules, one or more, in which case there's no primary maintainer - why not? 15:33:17 nirik: for b, you could look up what modules include the component and... pick one? I don't know 15:33:23 nirik: for c, it's effectively orphaned, I'd say 15:33:56 (this is getting nowhere, next week?) 15:34:01 do we expect users to do that? or maintainers? 15:34:07 yeah, we can punt 15:34:36 next week :) 15:34:42 +1 15:34:57 +1 15:34:58 +1 15:35:13 +1 15:35:18 +1 next week - I think there's a lot to discuss and related to the other ticket we've punted. 15:35:23 cool, let's move on 15:35:44 #topic #2033 F30 Change: Deprecate Sonatype OSS Parent 15:35:46 .fesco 2033 15:35:47 bowlofeggs: Issue #2033: F30 Change: Deprecate Sonatype OSS Parent - fesco - Pagure.io - https://pagure.io/fesco/issue/2033 15:36:14 should we discuss these java changes as a group? 15:36:23 please 15:36:24 or just go through each? 15:36:24 * nirik nods. 15:36:29 group please 15:36:37 This is one of several tickets tied together by sgallagh's comment in https://pagure.io/fesco/issue/2036 15:37:07 Yeah, I realize the current policy is to do the virtual Provides, but as no tools currently exist to read them, it seems wasteful to me. 15:37:08 sgallagh: i don't personally mind the virtual provides 15:37:19 bowlofeggs: It seems to me that the actual discussion is almost entirely about deprecated() and https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/ 15:37:32 mizdebsk says the java sig will use these 15:37:38 sgallagh: tool sbroken shouldn't block this 15:37:40 Yeah, I think it's fine to declare all these packages deprecated and find ways to avoid adding new content with them 15:37:41 *tools 15:37:57 But I think growing the repodata for zero benefit is ridiculous 15:38:02 FedoraReview is getting new devs and this might be solved soon 15:38:04 Our repodata is already far too large 15:38:23 sgallagh: aren't we talking about relatively little data here in these proposals though? 15:38:28 mhroncok: I'd rather that we maintain this deprecation data in a separate source (maybe FPDC?) 15:38:32 sgallagh: the few deprecated() lines are hardly measurable compared to the total size 15:38:41 i'd think just a few tens of bytes per package? 15:39:14 For today, sure. 15:39:26 proposal... 15:39:33 sgallagh: so you want to reject a proposal that builds on existing tooling in favour of something which is currently in early development? 15:39:39 If this remains the policy (particularly as the Python2->3 migration happens... or Golang changes...) isn't it going to grow? 15:39:41 deprecated packages won't be kept forever, so there's that ;) 15:39:49 zbyszek: No, you misunderstand. 15:39:51 we approve as is, sgallagh to porpose laternate solution for deprecated() later, we can fix the packages thta provide deprecated() once the new thing is agreed 15:40:00 mhroncok: +1 15:40:03 mhroncok: I'm fine with that. +1 15:40:06 mhroncok, +1 15:40:07 mhroncok: +1 15:40:07 contyk: There doesn't seem to be any mechanism/plan to remove deprecated packages :-) 15:40:15 +1 too 15:40:21 +1 obviously 15:40:23 mhroncok: +1 15:40:24 mhroncok: Though I'd really like to ask for a hard sunset date on these 15:40:27 +1 15:40:31 +1 as well 15:40:40 cool, that's +9 i think 15:40:42 * nirik would prefer working with FPC to change this, since they approved it... 15:40:52 do we want to count that vote for all teh java packages? 15:40:53 sgallagh: that's also allowed in the FPC guidelines, you can Provides: deprecated() = YYYYMMDD 15:41:05 all the java tickets i mean? 15:41:08 bowlofeggs: my vote would apply to all of them 15:41:09 bowlofeggs: Yes 15:41:12 cool 15:41:13 yep 15:41:19 yes 15:41:24 yes 15:41:26 #action sgallagh will propose a new way to deprecate packages 15:41:27 * sgallagh loathes bit-rotting packages. 15:41:36 #agreed APPROVED (+9, 0, -0) 15:41:50 ok, i'm going to skip the other java topics 15:41:53 moving along… 15:42:02 #topic #2038 Rebase of systemd in F29 15:42:04 .fesco 2038 15:42:06 bowlofeggs: Issue #2038: Rebase of systemd in F29 - fesco - Pagure.io - https://pagure.io/fesco/issue/2038 15:42:21 let's see what 241 brings 15:42:51 I'd very much liek to have it in rawhide ofr at least a few weeks 15:42:54 I'm glad the regressions were identified before we acked it 15:43:08 new regressions can be found in 241 15:43:14 yep 15:43:35 I feel like the experience we saw with 240 is pretty strong evidence that a blanket approval should *not* be granted, honestly. 15:43:41 I don't mind updating it in F29 if it's handled very carefully, having it in rawhide for some time is IMHO a must 15:43:50 I'm not specifically against this, since I think zbyszek is in the best position to judge his own package, but I'm *generally* against rebases of major system components for stable releases, since it's only a matter of time until we screw up and cause huge problems for our users and we don't have the mechanisms in place to catch/recover from that 15:44:14 It's too critical of a system 15:44:18 mhroncok: waiting in rawhide was always the plan 15:44:22 I'm fine with systemd maintainers coming and asking for rebases, but I don't think I want to pre-approve them. 15:44:42 sgallagh: +1 15:44:43 (sorry if that went through twice; I'm getting frequent disconnects today and I wasn't sure if it sent) 15:44:52 i'm actually ok with the proposal despite the risk, because i care more about it being backwards compatible and zbyszek documented the various incompatibilites and workarounds for all of them 15:44:55 (sgallagh: BTW current rawhide has 17 deprecated() packages, 7 have python2 in the name) 15:45:07 otaylor: the problem is that we don't have enough man power to usefully backport fixes to previous Fedora releases 15:45:16 Or to put it differently, 15:46:13 I think the time spent to backport patches would be better spent using the same version in multiple Fedora releases and spending more time on testing that one version. 15:46:26 +1 15:46:35 zbyszek: I wonder if those fixes actually matter that much? Generally, once someone gets f29 working, it's working. 15:46:36 well, sort of 15:46:49 as long as all the versions are backwards compatible 15:47:08 i haven't personally be experiencing issues i know of with systemd in f29 15:47:10 zbyszek: I can completely sympathize with that. Though a rebase has to be treated a bit differently than a regular update. On the kernel side, we do a test day for rebases. It actually gets a decent amount of traction, and helps. 4.19 excluded, where we had low turnout for some reason 15:47:58 test day, maybe even promoted on Fedora magazine and social media migth be a great idea for this 15:47:59 zbyszek: I'm not saying that each fix isn't important to some group of people, but there's a real risk/benefit tradeoff 15:48:58 mhroncok: Yes, promoting the test day made a huge difference in turnout. sumantro is a huge help in coordinating all of that 15:49:24 I guess I should talk with sumantro if organizing something like this for systemd would make sense 15:50:13 * nirik nods 15:50:24 It may, or may not. On the kernel side, we have a lot of hardware that wouldn't get tested otherwise, but it has been more useful than just updates-testing. 15:50:29 zbyszek: can we deffer to deicsion after this is in rawhide? 15:50:50 the kernel also has an easy way to boot the old one when there's a problem (though i've never needed to use it) 15:51:10 true 15:51:25 mhroncok: yeah, let's defer for now 15:51:30 * sgallagh has needed that feature on numerous occasions 15:51:36 cool, anyone opposed to deferral/ 15:51:39 ? 15:51:42 Though, admittedly, not in the last year or two 15:51:51 well i should s/never/never on fedora/ 15:52:06 * bowlofeggs runs gentoo at home too and has made plenty of non-bootable kernels there haha 15:52:43 ok, let's move on 15:52:54 zbyszek, I am all game :) 15:52:56 though deffering so much stuff only makes next week's meeting longer ☺ 15:53:09 #topic #2045 Unresponsive maintainer: Pradeep Kilambi 15:53:11 .fesco 2045 15:53:12 bowlofeggs: Issue #2045: Unresponsive maintainer: Pradeep Kilambi - fesco - Pagure.io - https://pagure.io/fesco/issue/2045 15:53:19 sumantro: thanks, let's talk later 15:53:54 zbyszek, sure :) 15:54:02 OK, we gave Pradeep some extra time and no response. 15:54:14 +1 to proceed with the non-responsive maintainer process 15:54:16 i'm +1 to accept the ticket 15:54:19 +1 15:54:23 +1 15:54:27 +1 15:54:33 +1 15:54:34 +1 15:54:38 so... what exactly does that mean here? 15:54:47 reassign just this one package? 15:55:08 nirik: yeah i think that's what's being asked for. i guess we could consider orphaning his packages too? 15:55:35 right, if they are not responsive at all.... all their other packages are likely not attended either 15:55:39 orphan it all 15:55:39 (if there are more packages actually) 15:55:53 feels like it's a request to trigger the process, so all of it, yes 15:55:57 they have 14 packages 15:56:13 well, I guess they aren't poc on all. 15:56:16 proposal: orphan all of pradeep's packages 15:56:20 +1 15:56:22 anyhow, +1 to reassign this one and orphan the rest. 15:56:28 bowlofeggs: +1 15:56:45 +1 seems improbable that a maintainer is unresponsive for just one package 15:56:50 nirik: the reporter said they weren't interested in maintaing it 15:57:10 or... not that either 15:57:15 it's not what they are pursuing 15:57:21 contyk: the reporter did ask for commit access in their initial post 15:57:25 https://src.fedoraproject.org/user/pkilambi shows one commit in February and one in July 15:57:48 though i guess we could orphan it too if the reporter doesnt' want it 15:57:53 i see that they said that in a later comment 15:57:57 No, the reported asked for access 15:58:27 zbyszek: "As I said, I'm really only looking to push an update here, not ownership per se. " 15:58:31 we could give it tot he reporter anyway under the "you touched it last!" rule 15:58:50 it's easier to orphan the package if the reporter doesn't want it 15:58:53 well if they don't want it, let's just orphan it too then 15:58:54 but of course without a point of contact it will get retired. ;) 15:59:05 proposal: orphan all of pradeep's packages, including this one 15:59:09 it doesn't involve releng tickets 15:59:09 I say we give it to them and say tehy are free to ropahn it 15:59:15 Well, without a POC it'll be in the nag-list and someone will either pick it up or it'll die. 15:59:16 +1 15:59:20 +1 15:59:23 +1 15:59:28 +1 (whatever) 15:59:33 haha 15:59:39 +1 15:59:47 +1 still 16:00:07 otaylor, tyll: ? 16:01:00 bowlofeggs: I don't feel I have a great sense of the unmaintained package process, at this point, so would rather abstain +0 16:01:05 ok 16:01:38 Yeah, looking at the various packages of pkilambi, there has been no significant activity since 2 years ago 16:01:45 #agree orphan all of pradeep's packages, including this one (+7, 0, -0) 16:02:03 #topic #2047 Need +1: policy change re. module default stream changes & Fedora Changes 16:02:05 .fesco 2047 16:02:07 bowlofeggs: Issue #2047: Need +1: policy change re. module default stream changes & Fedora Changes - fesco - Pagure.io - https://pagure.io/fesco/issue/2047 16:02:07 wait, no 16:02:12 zbyszek: ? 16:02:21 that's not what I voted for 16:02:39 zbyszek: ah i guess it was ambiguous whether we were voting on my proposal or mhroncok's 16:02:42 the proposal was to give the one package and oprhan the others 16:02:42 ok 16:02:52 revote? 16:02:57 please 16:03:06 #topic #2045 Unresponsive maintainer: Pradeep Kilambi 16:03:08 .fesco 2045 16:03:11 bowlofeggs: Issue #2045: Unresponsive maintainer: Pradeep Kilambi - fesco - Pagure.io - https://pagure.io/fesco/issue/2045 16:03:15 i dont' feel strongly about which proposal we use 16:03:30 shall we do a vote on mhroncok's instead? 16:03:34 i'd +1 it too 16:03:49 Maybe let's instead vote which one peoople prefer? 16:03:52 that person doesn't seem to be interested, they just wanted that one update; no reason to force it 16:03:59 so what's the proposal we're voting on now? 16:04:09 * nirik can be +1 to either. 16:04:23 is anyone against either? 16:04:32 +1 to orphan all, +0 to ownership transfer + orphaning 16:04:32 zbyszek: I think the real question is which does the ticket filer prefer? 16:04:47 the ticket filer said they don't want it 16:04:53 I am +1 to either 16:04:54 so it might be weird for us to give it to them anyway 16:04:56 we could also just ask them. 16:05:00 jforbes: yeah, so maybe let's keep the current vote and ask the ticket filer if the want the package 16:05:07 zbyszek: sure 16:05:14 bowlofeggs: OK, sorry for the noise ;) 16:05:28 zbyszek: so does that mean the count is correct? you are +1 to the proposal i wrote? 16:05:34 yes 16:05:36 ok cool 16:05:46 #topic #2047 Need +1: policy change re. module default stream changes & Fedora Changes 16:05:48 .fesco 2047 16:05:49 bowlofeggs: Issue #2047: Need +1: policy change re. module default stream changes & Fedora Changes - fesco - Pagure.io - https://pagure.io/fesco/issue/2047 16:05:53 +1 16:06:09 +1, voted in the ticket 16:06:11 so... this was filed what... 7 hours ago? 16:06:19 nirik: yes 16:06:28 We have +6 in the ticket 16:06:32 * nirik reads it, since I was asleep when it was filed. 16:06:35 was reading it this morning, surprised it was already on the agenda 16:06:57