15:00:08 #startmeeting FESCO (2018-03-02) 15:00:08 Meeting started Fri Mar 2 15:00:08 2018 UTC. The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:08 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:08 The meeting name has been set to 'fesco_(2018-03-02)' 15:00:08 #meetingname fesco 15:00:08 #chair maxamillion dgilmore nirik jsmith sgallagh bowlofeggs tyll jwb zbyszek 15:00:08 The meeting name has been set to 'fesco' 15:00:08 Current chairs: bowlofeggs dgilmore jsmith jwb maxamillion nirik sgallagh tyll zbyszek 15:00:09 .hello2 15:00:11 #topic init process 15:00:12 bowlofeggs: bowlofeggs 'Randy Barlow' 15:00:28 .hello2 15:00:29 jsmith: jsmith 'Jared Smith' 15:00:38  15:00:40 morning 15:00:42 .hello2 15:00:46 sgallagh: sgallagh 'Stephen Gallagher' 15:01:08 .hello2 15:01:09 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:01:44 That's 5, let's start 15:01:59 #topic #1846 F28 approved Changes not in MODIFIED status (considered as not testable) 15:02:02 .fesco 1846 15:02:04 zbyszek: Issue #1846: F28 approved Changes not in MODIFIED status (considered as not testable) - fesco - Pagure - https://pagure.io/fesco/issue/1846 15:02:04 https://pagure.io/fesco/issue/1846 15:02:27 Does anyone have additional info on the Modularity change? 15:02:50 Hello 15:02:51 langdon said that sgallagh was going to join the meeting and give us a status update 15:02:56 And there he is :-) 15:03:00 we have branched and rawhide composes... but there are some pungi / config issues to work thru 15:03:26 Yeah, the short version is that the rel-eng changes are landing later in the cycle than I would have preferred. 15:03:29 * nirik stops, lets sgallagh update as he likely has more up to date info 15:03:56 We have pretty much everything we need in place on the packager side of things. 15:04:00 there's a patch for bodhi from jkaluza that is probably needed (i'm waiting on a response from him on the PR) 15:04:07 We can build modules and prep them for inclusion. 15:04:10 (for modularity) 15:04:34 ac.hello till 15:04:34 bowlofeggs: OK, I wasn't aware of that one. Could you provide a link (in #fedora-modularity is fine) 15:04:37 .hello till 15:04:38 tyll_: till 'Till Maas' 15:04:45 sgallagh: https://github.com/fedora-infra/bodhi/pull/2167 15:05:30 I think we're in pretty decent shape, but I couldn't mark the BZ as "testable" yet because the repo bits are still being fixed up. 15:05:52 From my conversation with lsedlar today, that looks *likely* to be resolved by EOB today 15:06:17 At which point we are probably good to go for Beta 15:06:33 OK, so I think we can just wait another week for all 4 changes. 15:06:39 zbyszek: Agreed. +1 15:06:54 i'm +1 to another week on all 4 15:06:59 The major remaining piece is going to be adding module content between Beta and Final 15:07:34 We will have some representative content available, but we want to grow that out to a better sample before final release 15:07:47 EOF 15:08:07 Ack. 15:08:31 +1 to granting another week to make a final decision 15:08:40 * nirik is fine with another week. +1 15:08:50 tyll_? 15:09:11 +1 for another week 15:09:45 OK, so now I need to do the agreed thingy? 15:10:26 yep 15:10:36 zbyszek: Yes. We don't have a formally-agreed format for it, but I usually use (+X, Y, -Z) to indicate +1's, -1's and 0's 15:10:48 #agreed FESCo will wait another week for the changes not in MODIFIED status (+6, 0, -0) 15:11:14 #agree FESCo will wait another week for the changes not in MODIFIED status (+6, 0, -0) 15:11:28 The #agreed is the correct format 15:11:49 Should I get a reply from zodbot? 15:11:51 yeah, it just doesn't ack anything in channel, only logs 15:11:52 no 15:12:01 Oh, OK. Sorry. 15:12:06 no problema 15:12:07 #topic #1845 389-ds-base and freeipa on 32 bit arches 15:12:07 .fesco 1845 15:12:07 https://pagure.io/fesco/issue/1845 15:12:07 :) 15:12:09 zbyszek: Issue #1845: 389-ds-base and freeipa on 32 bit arches - fesco - Pagure - https://pagure.io/fesco/issue/1845 15:12:41 i dont' feel like we got a lot of feedback abotu this one 15:12:56 * nirik hasn't been following the bugs 15:13:03 It's a mess... 15:13:04 it does kinda sound like it's not a toolchain bug 15:13:11 but a bug in 389 15:13:14 I asked again earlier today for feedback 15:13:20 bowlofeggs: Agreed -- but I'd still like more information 15:13:52 What exactly is the question before us, though? 15:13:57 Anybody have any friends/contacts on the 389 team? 15:14:05 i think they want to remove 389-ds from i686 15:14:12 or was it from all 32-bit? 15:14:19 that's even kinda unclear to me 15:14:19 bowlofeggs: It was all 32-bit 15:14:20 haha 15:14:21 Are we being asked to force 389/FreeIPA to ship i686 even though it's known to have memory corruption issues? 15:14:25 sgallagh: whether to reject the removal of support for i686 and require the maintainers to provide it for F28. 15:14:30 I feel like that's a bad precedent 15:14:32 And I was trying to figure out "Is this an i686 problem, or a 32-bit problem" 15:14:47 sgallagh: Exactly :-) 15:15:06 it does seem like it would be bad for us to force them to ship a corrupting build 15:15:18 So, here's my thought process 15:15:19 but i do think they should try to fix it 15:15:29 If this was happening on x86_64, we'd be blocking the release for this. 15:15:44 true 15:15:48 sgallagh: There are some hints that it *might* be happening on x86_64, but "much less often" 15:15:56 By Blocker/FE process rules, that means a *fix* for this is a guaranteed Freeze Exception. 15:15:58 are any 32-bit arches "primary"? 15:15:59 sgallagh: Hence the reason I'm trying to get more info 15:16:14 bowlofeggs: ARMv7 is primary for XFCE spin 15:16:17 bowlofeggs: Yes, armv7 15:16:25 oh man 15:16:28 But it's not a blocking deliverable for Server 15:16:46 And 389/FreeIPA are only blocking for Server installs 15:16:55 ah that's good to note 15:17:41 so basically, this is not a blocking package for any 32-bit arch 15:17:54 My feeling on this is that since there is significant evidence that this is going to cause issues for i686 users, dropping it from that architecture until it's figured out is a sane and reasonable answer. 15:18:20 sgallagh: but it's not entirely clear that it is corrupting or actually causing any issues. Instead some tests are failing and they are used as convenient excuse to drop support. 15:18:31 bowlofeggs: Right, if it was blocking there would be no debate here. 15:18:52 yeah, it's unclear to me too. lots of the toolchain people are looking into it too... 15:18:55 zbyszek: that's a good point too 15:19:12 "If this is a bug in our tools, let us fix it" 15:19:18 zbyszek: That is kind of the entire purpose of tests, though 15:19:27 To identify issues *before* the end-users get hosed :) 15:19:28 it sounds like the toolchain people dont' think this is a toolchain issue 15:19:29 I don't think we can force support if maintainers don't want it, but there's a time in the cycle to drop an architecture, and it's very late to do it now. 15:20:02 zbyszek: I don't think it's too late. It's a reasonable thing to put in the Beta Release Notes, of course 15:20:06 the title of the bug does specifically say i686 and not 32-bit in general 15:20:16 If we were past Beta, I'd be more hesitant 15:20:17 (just a note) 15:21:12 we have had talks about dropping i686 all together before 15:21:16 bowlofeggs: yeah, but they note "This was a mistake on my part, as I didn't realize arm was 32bit. So arm will also be excluded in f28. So the original bug description was correct. " 15:21:17 there is the sig for it and what not 15:21:20 * sgallagh is attempting to summon some of the 389 folks 15:21:37 nirik: oh, so maybe the bug title should be updated 15:22:02 i'm inclined to ask some questions on the bug report to try to get more info 15:22:18 1) should we update the bug title to say "32 bit" instead of i686? 15:22:19 bowlofeggs: it's "389-ds-base and freeipa on 32 bit arches 15:22:21 " 15:22:24 So, I think I'm fine with killing off 32-bit support in F28. I wish it had been done more intentionally as a planned Change, but I think we have time to do it. 15:22:36 bowlofeggs: Please do -- my email to the devel list didn't seem to trigger a response. 15:22:37 2) Do we know real world use cases that cause problems, vs. test harnesses causing problems? 15:23:06 sgallagh: yeah that's an option - we could just grant a real late change request to this 15:23:17 Let me ask the question differently: what does it cost us to drop it? 15:23:41 sgallagh: a cascade of lost support for lots of things? 15:23:52 nirik: Sorry, explain? 15:23:54 yeah i think this does kill a tree of packages 15:23:56 or shipping other things on 32 bit with a serious bug other packages don't know about? 15:24:01 sgallagh: this is a dependency of other things 15:24:10 well, 389 goes, freeipa goes, N goes, etc 15:24:18 this is a dammed if you do, dammed if you don't situation haha 15:24:21 bowlofeggs: Pretty much only the FreeIPA stack which doesn't need to be run on the same hardware as its clients. 15:25:16 so do we want to proceed with asking them to file a change to drop this stuff, or do we want to ask question of them and wait another week? 15:25:17 * jsmith has to drop offline for a few minutes, but has voted on the tickets in Pagure 15:25:28 +1 for ask questions, wait a week 15:25:33 I'd prefer to have more info... 15:25:33 +1 too 15:25:39 bowlofeggs: Both? 15:25:46 if questions, do people want ot add more questions to the 2 i listed above? 15:25:54 * bowlofeggs volunteers to write them on the bz 15:25:56 If they feel strongly that this should be dropped, I think asking them to write up a Change Proposal for us is reasonable 15:26:05 sgallagh: sure 15:26:05 sgallagh: +1 15:26:28 sgallagh: +1 15:26:30 bowlofeggs: 3) Can you provide evidence that the issue is not also present on supported architectures? 15:26:41 cool 15:27:07 +1 for a proper change proposal 15:27:26 #action bowlofeggs will post questions from FESCo to the 389-ds BZ and ask for a change proposal if they feel strongly it should be dropped 15:27:46 FTR: dnf -C repoquery --whatrequires 389-ds-base --alldeps --qf %{name}|sort -u 15:27:49 389-admin 15:27:52 389-ds 15:27:54 389-ds-base-snmp 15:27:57 freeipa-server 15:27:59 migrationtools 15:28:02 slapi-nis 15:28:26 OK, can we move on? 15:28:29 engineering is hard 15:28:29 haha 15:28:32 sure 15:28:32 That's the FreeIPA stack and nothing else 15:28:41 if anyone thinks of more questions, let me know 15:28:49 So, another messy thing: 15:28:51 #topic #1820 Adjust/Drop/Document batched updates policy 15:28:51 .fesco 1820 15:28:51 https://pagure.io/fesco/issue/1820 15:28:53 zbyszek: Issue #1820: Adjust/Drop/Document batched updates policy - fesco - Pagure - https://pagure.io/fesco/issue/1820 15:29:09 this one is pretty contentious 15:29:22 * nirik nods. 15:29:30 i do agree that adding one more repo would make the angry people happier, but i don't know if we have the resources to do that 15:29:34 nirik: do we have the resources to do that? 15:29:35 I'm still pretty much firm on my comment https://pagure.io/fesco/issue/1820#comment-488614 15:30:09 it wouldn't be hard to make bodhi enforce it i dont' think 15:30:10 we could possibly do it, but I wonder if it would be used by like the 10 people who want it on devel list and no one else. 15:30:37 nirik: haha yeah, and it would be a lot of resources for 10 people 15:30:46 yeah. 15:31:03 i do still think that jdieter's proposal could make things nicer too 15:31:08 (the delta repo files) 15:31:16 though i don't know how long that would take to implement 15:31:21 he seems pretty devoted to it so far 15:31:37 Most of the arguments right now amount to "Since I don't push to batched, there are updates every day anyway. Therefore batched is useless" 15:31:45 I really think batched needs to be *mandatory* 15:31:50 sgallagh: we could try a 'soft' version of that... just have releng not push stable branches unless there's a urgent update... for a week and see if anyone cares/notices. 15:32:01 nirik: yeah that would be easy 15:32:07 nirik: Hmmm, that's an interesting idea 15:32:08 That's cool 15:32:37 well, it would be more work for whoever is on push duty to check... but otherwise yeah 15:32:55 nirik: That feels to me like something that could be scripted 15:32:55 nirik: i could add a flag to bodhi-push to do taht automagically without too much trouble 15:33:09 I am pretty sure that people notice delays, because they already notice shorter delays when there are bugs 15:33:43 nirik: bodhi-push --severity urgent 15:33:52 (doesn't exist yet, but wouldn't be hard) 15:34:42 yeah, dunno. I guess we could try it next week and see what feedback we get... 15:34:59 that sounds fine to me. i'm also amenable to sgallagh's proposal 15:35:36 it hink i agree that adding another repo might have an undesirable effort/reward ratio 15:35:37 That doesn't solve all the issues, in particular it doesn't answer the question of how to test those batched updates, but it'll give us more information, so I'm a cautious +1 15:35:53 well, just trying it might give more data to decide if we should enforce it or not 15:36:02 Exactly. 15:36:07 zbyszek: well, updates-testing... like any others 15:36:11 zbyszek: the batched updates stay in the testing repo, so they get tested just like normal testing updates 15:36:51 nirik: Well, the plan around batched was that we'd run a battery of automated tests against the stuff we were about to push as a complete unit 15:36:55 jsmith, tyll_: you have thoughts on this? 15:36:56 Which we can't do in the "soft" version 15:37:07 But I agree, this approach would at least get us some useful information. 15:37:42 sgallagh: yeah we don't have what we need to test them as a batch now, though i think mostly that would come down to creating a new koji tag and getting taskotron to use it 15:37:43 instead of an extra repo I would love to see an option in dnf so people can just filter on urgent updates for daily updates and other updates when they are ready 15:37:44 sure, we might want to involve QA and see how hard it would be to do that testing... 15:37:47 +1 to nirik's soft solution 15:38:01 it is there for security issues already 15:38:07 tyll_: That's already present in PackageKit, actually 15:38:31 i'm +1 to nirik's suggestion 15:38:38 Oh, urgent but not security? 15:38:41 Eh, whatever. 15:38:52 yeah urgent is what is used today 15:38:54 oh, and newpackage 15:39:07 which causes metadata to change too 15:39:25 at the time that was suggested, saving metadata downloads wasn't a goal in mind for me 15:39:40 so that's why newpackage updates are also sent straight to stable 15:40:07 not all security updates are really important 15:40:17 and not all bug fixes are "unimportant" 15:40:21 * nirik wonders how many urgent updates we even have 15:40:31 so that's why we used the severity instead of security to choose stable vs. batched 15:40:49 nirik, me, sgallagh, bowlofeggs voted. tyll_, jsmith ? 15:41:13 not sure if maintainers even change the severity for updates, since it did not really matter in the past 15:41:35 nirik: there have been 503 ever 15:41:36 * sgallagh always has, on the grounds that it might one day matter :) 15:41:37 yes, you can set it to whichever you like 15:42:04 zbyszek: the proposal is to delay all updates for a week unless there are urgent ones? 15:42:31 tyll_: Not for a week: until Tuesday 15:42:57 nirik: 62 urgent updates have happened in f27 so far 15:43:13 tyll_: Up to a week. If there is anything urgent, everything goes out. At least that's how I understood nirik's proposal. 15:43:17 since it is always good to get some data, +1 to try it 15:43:34 stable branches only push out when there is an urgent update pending on them or it's tuesday. 15:43:58 but IMHO it is not a good final solution 15:44:20 i think it's a social experiement 15:44:24 yeah, I was just wanting to get more data. 15:44:32 but if it pushes maintainers to better categorize their updates, it would be a win 15:44:38 we can use it to help us make a decision about what to do 15:44:44 tyll_: Right. Assuming this passes with little content, the final solution (in my mind) is just enforcing batched. 15:46:07 (better patch wednesday than on tuesday) 15:46:09 sgallagh: im my mind batched would be better implemented in the client 15:46:29 it would allow more flexibility to decide when to get the updates 15:46:50 tyll_: There are pros and cons there, but we should probably move to the next topic 15:46:57 Sorry, I dropped off for a moment. We had 5 +1 to nirik's proposal. 15:47:09 yeah, barring the metadata issues client side might indeed be a lot better 15:47:14 nirik: can you type up an #action item? I'm not sure about the exact wording. 15:48:06 #action next week updates will only be pushed to stable when there is an urgent pending stable update or tuesday after batched promotion. Feedback will be gathered and we will revist next meeting. 15:48:14 Thanks. 15:48:19 = New business = 15:48:19 self contained changes: 15:48:19 #topic #1856 F29 Self Contained Change: FedoraScientific VagrantBox 15:48:19 .fesco 1856 15:48:19 https://pagure.io/fesco/issue/1856 15:48:21 zbyszek: Issue #1856: F29 Self Contained Change: FedoraScientific VagrantBox - fesco - Pagure - https://pagure.io/fesco/issue/1856 15:48:45 +1 15:48:51 +1 15:49:03 +1 15:49:07 Oh, hang on 15:49:16 Did they get rel-eng approval? That's required for new spins 15:49:22 err, new media 15:50:22 https://pagure.io/releng/issue/7324 15:50:23 OK, they have requested it 15:50:24 We're good 15:50:27 No answer so far. 15:50:37 do we need to wait for releng? 15:50:43 or just make sure they filed the ticket? 15:50:45 zbyszek: I'm comfortable with the fact the ticket exists 15:50:46 I think we need to wait. 15:50:55 https://labs.fedoraproject.org/en/scientific/ 15:51:14 Nah, we can approve it and if rel-eng says no we activate the Contingency Plan 15:51:20 +1 15:51:32 sgallagh: OK, if you say so 15:51:47 shouldn't this change have a deliverables section? 15:51:56 We had had more votes in the ticket, let me count them 15:52:33 oh it does have a list of deliverables 15:52:37 under the releng ticket 15:52:43 bowlofeggs: it's also on the change page 15:52:52 ausil, jwb, jsmith were +1 15:52:56 +1 15:53:11 #agree F29 Self Contained Change: FedoraScientific VagrantBox 15:53:29 #undo 15:53:29 Removing item from minutes: AGREED by zbyszek at 15:53:11 : F29 Self Contained Change: FedoraScientific VagrantBox 15:53:53 #agree F29 Self Contained Change: FedoraScientific VagrantBox is accepted (+8, 0, -0) 15:53:54 i guess that means #agree works too 15:54:11 #topic #1854 F29 Self Contained Change: Drop Legacy GTK+ GUI in wireshark 15:54:15 .fesco 1854 15:54:17 zbyszek: Issue #1854: F29 Self Contained Change: Drop Legacy GTK+ GUI in wireshark - fesco - Pagure - https://pagure.io/fesco/issue/1854 15:54:17 https://pagure.io/fesco/issue/1854 15:54:44 jwb, jsmith voted +1 in the ticket 15:54:48 +1 15:54:52 +1 15:54:53 +1 15:54:55 +1 ftr 15:55:13 tyll_? 15:55:27 +1 15:56:00 #agree F29 Self Contained Change: Drop Legacy GTK+ GUI in wireshark is accepted (+7, 0, 0) 15:56:20 #topic #1852 F29 Self Contained Change: No more automagic Python bytecompilation 15:56:24 .fesco 1852 15:56:25 zbyszek: Issue #1852: F29 Self Contained Change: No more automagic Python bytecompilation - fesco - Pagure - https://pagure.io/fesco/issue/1852 15:56:26 https://pagure.io/fesco/issue/1852 15:56:33 * mhroncok is here 15:56:44 jwb, jsmith voted +1, +1 15:56:51 Seems reasonable to me. +1 15:56:54 +1 15:57:03 Automatic byte-compilation in random places has bit me in the past 15:57:27 this is a really nice write up 15:57:30 +1 15:57:37 +1 15:58:11 tyll_? 15:58:14 +1 15:58:32 * jsmith is back 15:58:34 (at least for a minute -- on mobile connection) 15:58:45 #agree F29 Self Contained Change: No more automagic Python bytecompilation is accepted (+7, 0, 0) 15:58:49 thanks 15:58:54 jsmith: go away, you voted already ;) 15:59:04 #topic #1851 F29 System Wide Change: Remove GCC from BuildRoot 15:59:04 .fesco 1851 15:59:05 https://pagure.io/fesco/issue/1851 15:59:06 zbyszek: Issue #1851: F29 System Wide Change: Remove GCC from BuildRoot - fesco - Pagure - https://pagure.io/fesco/issue/1851 15:59:16 zbyszek: You can't get rid of me that easily :-p 15:59:33 +1 to gcc 15:59:37 +1 15:59:43 jwb voted +1 in the ticket 15:59:47 jsmith: You voted on this one twice :-P 15:59:51 +1 from me 15:59:57 I was +1 in the ticket, so +1 here also 16:00:13 sgallagh: Then this one makes three :-) 16:00:18 sgallagh: Vote early, vote often :-) 16:00:43 +1 16:01:44 #agree F29 System Wide Change: Remove GCC from BuildRoot is accepted (+7, 0, 0) 16:01:52 #topic #1850 F29 Self Contained Change: True Noarch Erlang Packages 16:01:52 .fesco 1850 16:01:52 https://pagure.io/fesco/issue/1850 16:01:53 zbyszek: Issue #1850: F29 Self Contained Change: True Noarch Erlang Packages - fesco - Pagure - https://pagure.io/fesco/issue/1850 16:02:26 jwb voted +1 in the ticket 16:02:29 +1 16:02:33 jsmith voted +1 in the ticket 16:02:44 +1 16:02:46 +1 16:03:11 +1 16:03:23 +1 to my own proposal :) 16:03:34 #agree F29 Self Contained Change: True Noarch Erlang Packages is accepted (+7, 0, 0) 16:03:41 #topic #1855 F29 Self Contained Change: BINUTILS 2.30 16:03:42 .fesco 1855 16:03:42 https://pagure.io/fesco/issue/1855 16:03:42 bowlofeggs: Way to go :-) 16:03:44 zbyszek: Issue #1855: F29 Self Contained Change: BINUTILS 2.30 - fesco - Pagure - https://pagure.io/fesco/issue/1855 16:03:46 (and i finally have working code for it!) (it had to be delayed on f27 and f28 :( ) 16:04:09 +1 to binutils 16:04:10 I think this *might* need to be a system-wide change 16:04:18 but either way, I'm +1 16:04:46 +1 here, sorry it didn't make 28, but there was already a full plate there. 16:05:03 +1 to the change 16:05:06 +1 16:05:11 jwb voted +1 in the ticket 16:05:16 +1 16:05:25 i support making it system-wide 16:05:36 +1 to making in system wide 16:05:55 Yeah, +1 system-wide 16:05:59 It's already broken at least one systemd build, so yeah, not entirely self contained :) 16:06:42 Well, at least it didn't break anything *important*... 16:06:59 * sgallagh can feel zbyszek's glare through the screen 16:07:14 ;) 16:08:12 tyll_: , jsmith 16:08:36 +1 16:08:43 +1 16:08:50 (again) 16:09:17 #agree F29 Self Contained Change: BINUTILS 2.30 should be made a System-Wide Change (+6, 0, 0) 16:09:36 #agree F29 Self Contained Change: BINUTILS 2.30 is accepted (+7, 0, 0) 16:09:56 jwb is not here, so the count is different 16:10:03 #topic #1853 F29 System Wide Change: Enable dbus-broker 16:10:03 .fesco 1853 16:10:03 https://pagure.io/fesco/issue/1853 16:10:06 zbyszek: Issue #1853: F29 System Wide Change: Enable dbus-broker - fesco - Pagure - https://pagure.io/fesco/issue/1853 16:10:19 I suggest that we table this for another week 16:10:40 That seems reasonable 16:10:42 yeah i agree to wait 16:10:53 +1 to waiting 16:10:54 i also think the wording should be changed as suggested by jsmith 16:11:46 * nirik is ok waiting 16:11:52 #info F29 System Wide Change: Enable dbus-broker will be discussed next week 16:11:55 +1 to wait and reword 16:12:20 jsmith: I typed a reply to your comment in the ticket twice already, but I lost the connection at the crucial moment twice 16:12:31 and somehow the comment got lost. I'll try once more ;) 16:12:38 #topic #1848 Request to Authorize Removal of Blender Source Tarballs from Incorrect Place in Repository 16:12:42 .fesco 1848 16:12:44 zbyszek: Issue #1848: Request to Authorize Removal of Blender Source Tarballs from Incorrect Place in Repository - fesco - Pagure - https://pagure.io/fesco/issue/1848 16:12:44 https://pagure.io/fesco/issue/1848 16:13:43 i'm +1 as long as we archive the old repo 16:14:09 +1 to the same 16:14:10 Perhaps a better solution here would be for us to rename the git repo and make a shallow copy of the HEAD without the tarballs in it 16:14:18 Just a random idea: we can just rename the current refs to something that does not live in refs/heads, so won't be cloned automatically 16:14:19 I'm +1 16:14:29 Essentially, restart the repo history from today. 16:14:39 Which means that we don't have to remove anything, and people can still "git fetch " from the same location 16:14:51 sgallagh: That'd have the same issue, that you cannot use an old commit hash 16:14:55 I guess I'm a weak +1 if we archive the old repo and document where we archive such things and have a SOP for this process. 16:14:59 So basically set tags for the current state of things, and then rewrite the branches. 16:15:17 puiterwijk: that's a good idea - i didn't realize git clone didn't pull down things not referenced by HEAD 16:15:18 puiterwijk: I checked that, but if we make a tag, tags are clone dby default 16:15:22 Wouldn't they still get everything in a clone 16:15:28 zbyszek: right. I meant a tag outside of refs/heads 16:15:28 So a ridiculously-large checkout? 16:15:35 sgallagh: not if you stuff it in refs/archive/ 16:15:41 interesting... 16:15:46 git has a clone default of refs/heads/* and refs/tags/* if I recall correctly 16:15:47 +1 to puiterwijk's idea 16:15:56 That's how Github does their automagic refs/pull/$somenumber 16:16:03 also sounds like a good idea for all old branches IMHO 16:16:05 (and for those who didn't know: that even works with Pagure!) 16:16:14 or at least ancient branches 16:16:16 I'm +1 for puiterwijk's suggestion 16:16:37 That's also acceptable 16:16:40 yeah i'm +1 to puiterwijk's suggestion (and educated by it too!) 16:16:54 bowlofeggs: it doesn't depend on HEAD, it depends on refs/heads/ and refs/tags/ being the default clone refs :) 16:16:56 I don't think we want to do it for all old branches tho 16:17:16 yeah i think we just need it for this case 16:17:18 Yeah, I don't know about all old branches, I'd keep that for another discussion. 16:17:36 yes, it should be another discussion 16:18:18 So the nice thing is that if we decide to drop the old history, we can always still do that, this time by dropping the ref in refs/archive/. 16:18:32 So, I'm moving my +1 to puiterwijk's proposal 16:19:13 a 16:19:46 +1 puiterwijk 16:20:19 nirik: ? 16:20:40 +1 yes for this case 16:20:52 and we should document this (releng sops? wiki?) 16:23:18 For those who want to learn more: git refspec is the term you're looking for (https://git-scm.com/book/en/v2/Git-Internals-The-Refspec), which defaults to "refs/heads/*:refs/remotes/origin/*" 16:23:25 #agree Move branches with huge commits to refs/archive/ and create new sanitized branches (+6, 0, 0) 16:23:56 OK? 16:24:41 yeah 16:24:50 yep 16:24:56 #topic #1843 FAS bot account sponsoring 16:24:56 .fesco 1843 16:24:58 zbyszek: Issue #1843: FAS bot account sponsoring - fesco - Pagure - https://pagure.io/fesco/issue/1843 16:24:58 https://pagure.io/fesco/issue/1843 16:25:08 jwb voted +1 in the ticket 16:25:19 +1 to creating the account 16:25:40 +1 to creating the account 16:25:59 +1 16:26:04 +1 (with comments on the ticket) 16:26:28 i'm +1 to the idea, but i want to see sign off from infra in general, and from patrick for security 16:26:33 I think that the main thing that fesco needs to vote on is whether or not it gets sponsored as a packager. 16:26:35 if the bot gets compromised that will be bad 16:27:10 bowlofeggs: yeah, the code should be reviewed... 16:27:12 we have done this before for the cockpit user I think... 16:27:13 bowlofeggs: well, so far the policy has been that since it's their responsibility, they're personally responsible if it gets compromised, just like any random packagers' machine 16:27:35 well, "policy".... What I've regard things as so far 16:28:04 yeah if you are ok with that then i'm +1 16:28:37 Since it won't have any "special" permissions (i.e. just "packager"), I think that the security part of this should be handled as any random packager, since I can't audit packagers' machines either (nor would I want to.... That's a loooot of work) 16:28:50 And any random packager can write a script that does $randomstuff with their credentials 16:28:58 It just means they are solely personally responsible 16:29:15 github has a policy that bot users has to have their owner in bio 16:29:34 mhroncok: we have a request by them to create the bot, we can track down the owner :) 16:29:44 yeah that's a reasonable argument 16:29:49 Also, as with all packagers: the person who sponsors them is also partially responsible 16:29:56 puiterwijk: sure, I mean it might be good idea to ahve the information visible in FAS somehow 16:30:31 +1 to make the info visible 16:30:37 maybe even in the name? 16:30:48 nirik? 16:30:53 like usercont-bot 16:31:18 +1 to it... 16:31:29 how can any of you tell that i'm not a bot after all 16:31:42 * jsmith is now known as "botofeggs" 16:31:48 hahaha 16:31:48 bowlofeggs: You make more mistakes than most bots? ;-) 16:31:50 bowlofeggs: people have found out my "secret" long ago as well :) 16:31:50 also makes sense if the sponsor is from the user-cont team to make the relationship obvious? 16:31:57 sgallagh: haha 16:32:07 tyll_: I'm not sure that they are sponsors. But yeah, if they are, that'd be great 16:33:10 OK, so do we change the name from usercont to usercont-bot? 16:33:26 sure 16:33:28 there's no way to rename in fas. 16:33:32 you would have to make a new account 16:33:54 .fasinfo usercont 16:34:02 puiterwijk: User: usercont, Name: None, email: the.conu.bot@gmail.com, Creation: 2018-02-13, IRC Nick: None, Timezone: None, Locale: None, GPG key ID: None, Status: active 16:34:05 puiterwijk: Approved Groups: cla_done cla_fpca 16:34:32 I'd personally say that I'd like the privacy flag removed and the email updated to their team email or something, and then the info added to its name. That should be enough 16:34:47 puiterwijk: exactly 16:35:24 i don't mind it not having bot in the name, but that would be nice 16:35:27 i'm +1 either way 16:35:33 * tyll_ wonders how the bot signed the fpca 16:35:45 i hadn't realized the account was already made 16:36:04 the bot might also be violating google TOS, but that's not my problem :) 16:36:07 tyll_: by virtue of a human pressing the button. So again: on their personal name/term I'd say (legally) 16:36:36 OK, it seems we are in agreemment. 16:36:49 #agree FAS bot account sponsoring is accepted, with the provision that it should be clear that the account is a bot (+7, 0, 0) 16:37:13 Almost there 16:37:14 #topic The time of the next meeting. 16:37:14 Fesco members, please respond to the whenisgood poll! 16:37:18 zbyszek: and also, provided that the owners accept they're personally responsible (I'd say) 16:37:34 #undo 16:37:34 Removing item from minutes: 16:37:45 #undo 16:37:45 Removing item from minutes: AGREED by zbyszek at 16:36:49 : FAS bot account sponsoring is accepted, with the provision that it should be clear that the account is a bot (+7, 0, 0) 16:37:47 (I think that goes automatically in my mind, but would like to make it explicit) 16:38:34 what about this: FAS bot account sponsoring is accepted, with the provision that it should be clear that the account is a bot and that owners are responsible for any actions it takes the same as for their own actions 16:38:44 +1 16:39:08 +1 (non-counting obviously) 16:39:15 +1 sounds good 16:39:35 #agree FAS bot account sponsoring is accepted, with the provision that it should be clear that the account is a bot and that owners are responsible for any actions it takes the same as for their own actions (+7, 0, 0) 16:39:38 +1 16:40:05 I assume that everybody is fine with the slightly stricter provision. 16:40:07 Let's move on. 16:40:09 #topic The time of the next meeting 16:40:10 did I miss https://pagure.io/fesco/issue/1857 or is that scheduled for nex meeting? 16:40:36 #undo 16:40:36 Removing item from minutes: 16:41:12 #topic #1857 Retiring Django packages 16:41:12 .fesco 1857 16:41:14 zbyszek: Issue #1857: Retiring Django packages - fesco - Pagure - https://pagure.io/fesco/issue/1857 16:41:33 Sorry, Idon' must have dropped it from the schedule 16:41:57 np 16:42:13 i had a thought on this: isn't there going to be an LTS django that does support python 2? if so, should we just get these packages to use that? 16:42:16 +1 to the retiring 16:42:39 or are they all so dead that it's better to retire anyway? 16:42:40 bowlofeggs: it ends support soon. ;) 16:43:25 it is telling that the maintainers have not responded on any of the BZs 16:43:33 bowlofeggs: we only have that tls version as a compat package for apps 16:43:41 not for packaged libaries nothing depends on 16:43:55 +1, I can also retire them 16:44:14 yeah i'm +1 to retire, especially since these tickets have no responses from their maintainers 16:44:15 * mhroncok can retire them if agreed 16:44:16 +1 here 16:44:17 If they need to come back to life... we have modules 16:44:21 they've been open for more than a month 16:47:16 jsmith, vote? 16:47:40 +1 retire, BTW 16:47:43 +1 retire 16:48:02 #agree Retiring of Django packages is accepted (+6, 0, 0) 16:48:02 #action mhroncok to do the retirement 16:48:09 #topic The time of the next meeting. 16:48:22 There hasn't been much movement on this... 16:48:56 thanks 16:48:57 I guess everybody who is here find the existing time feasible ;) 16:49:22 yeah we got only 1 more response since last week, for a total of 6 responses 16:49:31 and now we have only 3 30 minute slots available :/ 16:49:46 I don't like the current time, but I can live with it if it works for everyone else. 16:50:09 should we ask people to see if they can reschedule some things to open up a more agreeable time slot? 16:50:14 bowlofeggs: so 3 meetings a week then? 16:50:18 haha 16:50:33 http://whenisgood.net/fesco2018roundtwo/results/ss5khfp 16:50:46 sure, worth asking. 16:51:58 uh, I have actually more time, I thought this would be starting times 16:53:01 oh i interpreted it as meaning that you are available for all the 30 minute blocks you select 16:53:19 sgallagh dgilmore maxamilliohaven't repsonded 16:53:57 *maxamillioon 16:54:06 *maxamillioon 16:54:07 maxamillion ? 16:54:10 *maxamillion 16:54:13 Pff. 16:54:36 I think I missed the email 16:54:55 I'll resend to the three people. 16:55:00 he is out spending time with his newborn... 16:55:00 OK, let's move on. 16:55:15 #topic Opne floor 16:55:33 * jsmith has nothing for the open floor 16:56:12 Anyone? 16:56:18 * tyll_ will miss next meeting due to NHO 16:56:30 tyll_: congrats! :) 16:56:37 nirik: thank you 16:56:39 tyll_: enjoy :) 16:56:42 tyll_: \o/ 16:56:44 and welcome! 16:56:49 tyll_: nice! 16:56:50 tyll_: congratskis! 16:56:55 thank you all! 16:57:27 #topic Next week's chair 16:58:00 I can do it again, I think I'm getting the hang of it. Unless somebody wants to. 16:58:50 i did it last week, not it! 16:59:24 OK, let's keep this under 2h. 16:59:53 #action zbyszek will chair next meeting 16:59:53 #action zbyszek will send a reminder e-mail about the meeting voting time 17:00:18 Anything else? If not, I'll close in 30s. 17:00:46 zbyszek: note that 30s is already >2h, so "under 2h" is not possible anymore :) 17:01:02 :D 17:01:04 I'm ona slow connectoin. It was still <2h when I was typoing. 17:01:18 Anyway… 17:01:21 … 17:01:27 Thank you all. 17:01:28 #endmeeting