18:00:17 #startmeeting FESCO (2015-02-11) 18:00:17 Meeting started Wed Feb 11 18:00:17 2015 UTC. The chair is mitr. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:19 #meetingname fesco 18:00:19 The meeting name has been set to 'fesco' 18:00:21 #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh 18:00:21 Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza 18:00:23 #topic init process 18:00:25 Hello everyone 18:00:42 Hi 18:00:44 * rishi waves 18:00:54 * crobinso is here for merge review discussion 18:01:13 hey 18:01:21 hellos 18:01:30 crobinso: (Because of the number of tickets that one is next to last on the agenda) 18:01:39 CLOSE THEM ALREADY 18:01:42 * jreznik is here in case fesco would need him, ready to server 18:01:54 jreznik, you should be ready to workstation too ;) 18:01:55 * mattdm is lurking 18:02:04 mitr: okay, someone ping me if he comes up please, I suck at IRC 18:02:11 s/he/it/ 18:02:32 jwb: ah :) and +1 to previous one, close them all 18:02:36 jwb: merge reviews are the new 998 18:02:49 ajax, they are entirely worse, but i see what you're getting at 18:03:18 +1 to closing merge reviews 18:03:28 hi all 18:04:42 That’s 6, sgallagh_afk is afk, nirik wrote that he will likely not be able to attend, let’s start. 18:04:47 #topic Welcoming new FESCo members 18:04:57 New FESCo members, welcome! Departing FESCo members, thank you! 18:05:34 Is there any related administrative work outstanding? e.g. fesco list membership 18:05:45 it's good to be back, i suppose 18:06:00 are we going to change the time for FESCo meeting? or are we going to keep the current time? 18:06:32 thozza, to saturday's? 18:06:45 Checking won’t hurt. 18:06:49 i don't have much of a preference about time 18:06:58 so whatever works 18:07:17 #action mitr to send a whenisgood form, results to be discussed on the next meeting 18:07:28 moezroy: I was thinking about sunday 18:07:44 ;) 18:08:11 So, the mailing list—new members, are you on https://lists.fedoraproject.org/mailman/listinfo/fesco ? If not, please subscribe. 18:08:33 mitr: Yes, I already subscribed last week. nirik let me in. 18:08:34 Moving on. Since there have been no objections on fedora-devel, let’s move some of the long-standing items to the end and deal with the urgent ones first. 18:08:44 #topic #1384 F23 System Wide Change: Harden all packages with position-independent code - https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code 18:08:46 .fesco 1384 18:08:48 mitr: #1384 (F23 System Wide Change: Harden all packages with position-independent code - https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code) – FESCo - https://fedorahosted.org/fesco/ticket/1384 18:08:48 https://fedorahosted.org/fesco/ticket/1384 18:08:50 Kevin, in the ticket, was in favor of changing the default to hardened_build 1 in rawhide, and asking change owners to retarget this change for f23. 18:08:57 same 18:09:18 i mean, i guess 18:09:19 (The change has been updated for F23 in the mean time). 18:09:38 i'm commenting more on the worth of the feature really, i wouldn't expect it to make much difference outside of i686 18:09:49 I am +1 as well. (Note that this includes i686; I don’t personally think that’s worth worrying about, but others might.) 18:10:22 +1 from me as well 18:10:25 +1 18:10:48 +1 if i wasn't clear before 18:11:18 #agreed F23 System Wide Change: Harden all packages with position-independent code approved (+5) 18:11:22 +1 from me too. 18:11:32 thank you! 18:11:34 #undo 18:11:34 Removing item from minutes: AGREED by mitr at 18:11:18 : F23 System Wide Change: Harden all packages with position-independent code approved (+5) 18:11:39 #agreed F23 System Wide Change: Harden all packages with position-independent code approved (+5) 18:12:38 jreznik: Any objections to deferring the F23 mass rebuild timing discussion to some later time? (e.g. when you come with a proposal? ☺ ) 18:13:02 mitr: sure, it's not something we have to talk about now 18:13:20 I think we can deal with these three tickets as a block: 18:13:25 #topic #1390 F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades - https://fedoraproject.org/wiki/Changes/RpmOstree 18:13:27 .fesco 1390 18:13:28 mitr: #1390 (F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades - https://fedoraproject.org/wiki/Changes/RpmOstree) – FESCo - https://fedorahosted.org/fesco/ticket/1390 18:13:29 https://fedorahosted.org/fesco/ticket/1390 18:13:31 #topic #1396 F22 System Wide Change: Atomic Host - https://fedoraproject.org/wiki/Changes/AtomicHost 18:13:33 .fesco 1396 18:13:35 https://fedorahosted.org/fesco/ticket/1396 18:13:35 mitr: #1396 (F22 System Wide Change: Atomic Host - https://fedoraproject.org/wiki/Changes/AtomicHost) – FESCo - https://fedorahosted.org/fesco/ticket/1396 18:13:40 #topic #1397 F22 System Wide Change: Bare Metal Installer for Fedora Atomic Host - https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic 18:13:43 .fesco 1397 18:13:44 mitr: #1397 (F22 System Wide Change: Bare Metal Installer for Fedora Atomic Host - https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic) – FESCo - https://fedorahosted.org/fesco/ticket/1397 18:13:44 https://fedorahosted.org/fesco/ticket/1397 18:13:46 Proposal: Defer tickets 1390, 1396, 1397 until we get more specifics, remove meeting keyword until then. 18:13:55 yeah, +1. 18:14:05 that was all supposed to happen already, but i guess it didn't 18:14:16 fine with me, +1 18:14:22 right +1 to defer 18:14:23 mitr: +1 18:14:33 i'd like more time to read into the atomic stuff regardless 18:14:51 it's full of files and hardlinks. 18:14:57 +1, looks like they have got the patches into Anaconda. 18:15:17 #agreed Defer tickets 1390, 1396, 1397 until we get more specifics, remove meeting keyword until then (+6) 18:15:31 #topic #1392 Review scope of "Python 3 as default" Change for F22 18:15:33 .fesco 1392 18:15:34 mitr: #1392 (Review scope of "Python 3 as default" Change for F22) – FESCo - https://fedorahosted.org/fesco/ticket/1392 18:15:35 https://fedorahosted.org/fesco/ticket/1392 18:15:37 Proposal: Close this ticket, discuss the specifics in #1413 instead. 18:15:57 * mitr is apparently the bureaucratic close-for-mere-formalities person today 18:16:12 sure 18:16:17 if there are two places we're talking about this, yes, let's have only one 18:16:22 I am a bit clueless about Python. :/ 18:16:55 Can it be moved to target F23 or we will ask new ticket for it? 18:17:05 rishi, there's lots of time to learn :) 18:17:20 it should be moved to F23 18:17:25 mitr: +1 sure 18:17:26 paragan: The “Python 3 as default” Change page has not been deleted, and I assume it will be proposed and discussed for the F23 cycle. 18:17:30 jwb: I hope I am never encounter one in real life. :-P 18:17:36 mitr: exactly 18:17:36 (damn, I can't type) 18:17:47 heh 18:18:07 and for this Change I'd like to avoid moving to F23 automatically, it's more for next release review... 18:18:25 ok then +1 to close ticket 18:18:27 #agreed Close this ticket, discuss the specifics in #1413 instead. (+5) 18:18:35 Speaking of which, … 18:18:44 #topic #1413 F22 System Wide Change: Python 3 Migration Improvements - https://fedoraproject.org/wiki/Changes/Python_3_Migration_Improvements 18:18:46 .fesco 1413 18:18:47 mitr: #1413 (F22 System Wide Change: Python 3 Migration Improvements - https://fedoraproject.org/wiki/Changes/Python_3_Migration_Improvements) – FESCo - https://fedorahosted.org/fesco/ticket/1413 18:18:48 https://fedorahosted.org/fesco/ticket/1413 18:18:50 Kevin was +1 in the ticket. 18:19:19 +1 18:19:21 I am also +1, noting that the Change page might be a bit improved for more end-user-facing focus but that’s by no means a blocker 18:19:42 +1 18:20:45 +1 18:21:03 +1 18:21:11 #agreed F22 System Wide Change: Python 3 Migration Improvements has been accepted (+6) 18:21:20 #topic #1406 F22 System Wide Change: Systemd Package Split - https://fedoraproject.org/wiki/Changes/SystemdPackageSplit 18:21:22 .fesco 1406 18:21:23 mitr: #1406 (F22 System Wide Change: Systemd Package Split - https://fedoraproject.org/wiki/Changes/SystemdPackageSplit) – FESCo - https://fedorahosted.org/fesco/ticket/1406 18:21:24 https://fedorahosted.org/fesco/ticket/1406 18:22:01 * zbyszek is here 18:22:04 -1 from me, since both Lennart and Kay were clearly against it. 18:22:07 I am +1; the existence of fakesystemd is another reason why this is needed. 18:22:40 ooh, a non-unanimous vote 18:22:46 and i'm all out of popcorn 18:22:46 rishi: i'm sorry, where was that expressed? 18:23:00 ajax: https://lists.fedoraproject.org/pipermail/devel/2015-January/206889.html 18:23:06 ajax: In the fedora-devel thread; essentially saying that systemd API is a package deal. 18:23:07 and https://lists.fedoraproject.org/pipermail/devel/2015-January/206984.html 18:24:01 thanks 18:24:09 zbyszek: Will the systemd-filesystem idea work for you? 18:24:14 IMHO this is clearly an improvement; As the last time, I could go with “+1 but does not override package owners” 18:24:27 rishi: No. 18:24:30 rishi: That doesn’t work; other packages’ scriptlets depend on running systemctl 18:25:02 mitr: do they depend on it working, though 18:25:27 ajax: In the single-process-container scenario, no. 18:26:02 (This is where we could go into an extensive detour into whether this scenario is desirable or not.) 18:26:54 mitr: With my proposal, systemctl cannot be used to start a service, but it can be used to enable/disable/preset it, which is what rpm scripts care about. 18:27:19 zbyszek: Ah, sorry. Thanks for setting me straight. 18:28:09 With a hypothetical -filesystem package, enable/disable/presets would be lost. 18:29:43 are allowed to redundantly package files? 18:29:49 are we, even 18:30:20 ajax: “redundantly”? 18:30:32 ajax: if those files are the same it should not be a problem IMHO 18:30:43 mitr: same content at the same path, in multiple subpackages of a single srpm 18:31:22 ajax: i don’t see what that buys compared to having one more subpackage with the common files required by the other subpackages, only uncertainity about untested code paths. 18:32:34 mitr: we are talking about a strictly limited set of calls found in rpm macros, as prescribed by the packaging guidelines. 18:32:35 ajax: yes, that's allowed 18:33:29 I was previously against the split of only systemd-units, but given the use case for containers it makes sense. And should be reasonably doable although a lot of work for zbyszek. 18:33:36 so count me +1 for it 18:33:38 More votes? Questions? Concerns? 18:33:53 i mean, nothing's forever 18:34:16 +0 18:34:17 i think i see what kay/lennart are getting at but i'm not convinced 18:34:35 I am uncomfortable with pushing through a change in a package without getting its owners (who are also the upstream maintainers) on board. 18:34:48 so +1 and if it causes actual problems zbyszek can have them (and if they're too many we can undo it) 18:35:21 So we are at +3-1 1x0 and apparently no way to get this approved/rejected. 18:35:27 rishi: zbyszek is one of the downstream owners: http://pkgs.fedoraproject.org/cgit/systemd.git/ 18:35:50 I'm also upstream, fwiw :) 18:35:52 rishi: kay and lennart are not really the owners I think 18:35:55 rishi: Integrating packages that they make sense together (as opposed to making sense in how upstream sees them) is kind of the purpose of distributions, though. 18:36:11 rishi: zbyszek seems to be doing most of the stuff in Fedora WRT systemd 18:36:11 thozza: They are committers, like quite a few other people. 18:36:22 mitr: sure, but not the only owners 18:36:40 zbyszek: So, I guess you can convince Lennart and Kay, right? :) 18:36:51 Did you talk to them outside devel@lists.fp.o ? 18:37:02 So, defer for more votes? Ask specific questions? (And if we don’t approve the change but the package owner commits it anyway…) 18:37:06 rishi: Yes, I talked to them, and they are against. I don't think this will change. 18:37:43 We are at 15 minutes, discuss more or move on? 18:37:55 I saw that Colin Walters was not totally against the idea. Maybe he can help in convincing them? I don't know. 18:37:55 if it produces an os that works by all available metrics, then i don't see how fesco can object 18:38:21 ajax: right 18:38:24 are we concerned about being impolitic or are we concerned about the quality of work 18:39:11 'cause i'm pretty sure fesco is primarily not meant to be about diplimacy 18:39:13 That’s kind of my point; ultimately what we are talking about here is only the PR and general testing of the commit, if any. 18:40:00 * mitr arbitrarily decides in the interest of other tickets 18:40:02 #info No conclusion reached (+3 -1 1×0), will discuss next week 18:40:11 #topic #1377 enable kdump addon by default 18:40:14 .fesco 1377 18:40:15 https://fedorahosted.org/fesco/ticket/1377 18:40:15 mitr: #1377 (enable kdump addon by default) – FESCo - https://fedorahosted.org/fesco/ticket/1377 18:41:07 -1 to enabling it by default on all systems, since the Fedora kernel team is against it. 18:41:24 It seems undisputed that there are frequent hardware driver problems, so -1. 18:41:40 this would be a product question not a fedora question, right? 18:41:45 I could be +1 if kdump didn’t really work as long as it didn’t make the crash any worse, but this seems not the case. 18:42:00 ajax, that's a possibility. i don't think the ticket was raised that way though 18:42:04 ajax: Why would products differ in this decision? Because they implicitly mean different hardware? 18:42:40 mitr: somewhat yeah. i mean, if the drm support isn't functional, kdump isn't useful for workstation. 18:42:46 i would probably still object on a per product basis though, since none of the products actually have hardware requirements/specifications 18:43:26 that is true, all are built for all primary architectures... 18:44:07 In some ideal world the kdump _addon_ (with the “reserved memory” fields and the like) should not be needed either, just enable this by default. (None of the other major OSes need to ask the user whether to capture kernel backtraces, and just do it.) 18:44:33 uh, what? 18:44:41 kdump isn't for getting backtraces 18:44:50 it's like core files for the kernel 18:45:07 ABRT gets backtraces just fine in a large majority of cases 18:45:32 backtraces/minidumps/… Sorry, this comment was really irrelevant for the decision at hand anyway. 18:46:06 believe me, i would love to have working infrastructure to allow better debugging of kernel issues. but we don't have the man power or time to spend on fixing that infrastructure in fedora 18:46:31 spend a while getting it working, just to get back to the point of seeing 8000 intel WARN_ONs? nah :) 18:46:57 yeah i'm leaning -1 here 18:47:05 -1 18:47:07 -1 we don't need it default enabled. 18:47:34 jwb: Is there a known, easily understood set of hardware this works on? “Server hardware” is too vague I guess, but “Xen and KVM clouds”? 18:48:18 it needs a serial port 18:48:35 virt guests have other ways to get debug data. i don't think kdump is relevant there 18:49:06 basically, translate it to "physical hardware you would install RHEL on" 18:49:18 ajax: Is that a vote? 18:49:46 yes 18:49:52 #agreed Enabling the kdump addon by default was rejected (-5) 18:50:04 #topic #1408 New package/branch request processes (off bugzilla to pkgdb) 18:50:06 .fesco 1408 18:50:08 https://fedorahosted.org/fesco/ticket/1408 18:50:08 mitr: #1408 (New package/branch request processes (off bugzilla to pkgdb)) – FESCo - https://fedorahosted.org/fesco/ticket/1408 18:50:10 Kevin supported the 7-day waiting period in the ticket. 18:50:35 sounds fine to me too 18:51:01 +1 18:51:12 AFAICS there wasn’t any indication that the requests for unwated branches are an actual issue, just a concern; have I missed anything? 18:51:40 mitr: that's my impression as well. 18:51:56 +1 18:52:12 I have had an unwanted branch applied, but that was a long time ago. 18:52:17 If not, I don’t see a strong reason to impose the waiting period; OTOH just having the waiting period for both EPEL and non-EPEL branches might ultimately simplify both the code and the policy ☺ 18:53:02 If you're going to automate it, though, the system has to have a way of rejecting things that Red Hat ships in some way. 18:53:41 That and the "branch without realizing that it won't build/work in epel" issues are the only ones that come up on a semi-regular basis. 18:54:04 tibbs|w: That’s an EPEL-only concern, isn’t it? Not the situation for which pingou is asking for a decision. 18:54:44 I guess I’ll go with the majority, and counting ajax as +1 (right?) that gets us to +5. 18:54:48 mitr: yes 18:54:50 Sorry, just providing background. Someone mentioned unwanted branches, and I've seen pretty much all of the situations where that happens. 18:55:02 * ajax needs to be more explicit 18:55:13 #agreed Implement a similar waiting period for Fedora branch as we do for EPEL branch (+5) 18:55:28 #topic #1409 provenpackager request: mstuchli 18:55:30 .fesco 1409 18:55:32 mitr: #1409 (provenpackager request: mstuchli) – FESCo - https://fedorahosted.org/fesco/ticket/1409 18:55:32 https://fedorahosted.org/fesco/ticket/1409 18:55:34 Three +1 votes have arrived since, so the ticket can be closed. Do we want to deal with the policy ambiguity right now? 18:55:36 Kevin, in the ticket, supports automatic refusal of provenpackager requests if there are no votes. 18:55:46 Kind of surprised the cvsadmins wheren't CC'd on 1408, honestly. 18:56:00 i think so 18:56:21 Just repeating my +1. He seems to have the confidence of the people he works with. So no reason to object. 18:56:31 +1 18:56:43 mitr: I'm also +1 18:56:55 Is it possible to actually CC the packager-sponsors list/alias on those tickets? 18:56:56 Assuming all the votes above are for him becoming provenpackager? 18:57:11 mine is :) 18:57:16 So was mine. :) 18:57:23 mitr: well, +1 to accepting the ticket without even needing to vote here, but then also +1 if we do vote here 18:57:32 just all the affirmatives 18:57:35 I know Kevin sends one message to the list but it might be nice to see the updates as well. 18:57:36 Based on the information provided for Matej, I will +1 18:57:39 Yeah, mstuchli becoming a provenpackager is AFAICS a done deal. 18:58:41 tibbs|w: Editing http://fedoraproject.org/wiki/Provenpackager_policy to ask for a Cc: would work, at the cost of extra manual steps. Not suere whether we can automate it with trac. 18:59:39 As for the policy proposal, automatically refusing provenpackager requests if there are no votes: The policy says that people with no + votes and some - votes go to FESCo, and could actually be accepted for provenpackagers; it seems a bit strange that people to whom no object should end up worse off. 19:00:07 hah 19:00:15 yeah that's odd 19:00:28 So, 19:00:30 Proposal: Change http://fedoraproject.org/wiki/Provenpackager_policy step 4, s/In case of negative votes/If you haven’t been automatically approved/ (referring to rules in step 3, which avoids the duplication and ambiguity) 19:00:53 mitr: +1 19:01:01 * mitr is +1 for the record 19:01:42 +1 19:01:46 +1 19:02:14 +1 19:02:48 #agreed Change http://fedoraproject.org/wiki/Provenpackager_policy step 4, s/In case of negative votes/If you haven’t been automatically approved/ (+5) 19:03:02 #topic #1410 Updates Policy should try harder to prevent updates that break future updates 19:03:04 .fesco 1410 19:03:06 https://fedorahosted.org/fesco/ticket/1410 19:03:06 mitr: #1410 (Updates Policy should try harder to prevent updates that break future updates) – FESCo - https://fedorahosted.org/fesco/ticket/1410 19:03:08 Kevin was -1 in the ticket. 19:04:00 I found the bit about "all updates must be in the form of individual patches" to be a little extreme. :) 19:04:01 -1. i don't think the proposal is actually going to _fix_ things. it might help, but then again it's something the package maintainers can already do themselves 19:04:26 -1 to increase more time in testing 19:04:37 rishi: In other distros, that is normal, but it's a detail and I don't mind details too much. 19:05:08 -1 to the proposal as written. OTOH. 19:05:08 But I think if we don't increase time in testing, we are just going to keep breaking updates. 19:05:08 mcatanzaro: Yeah 19:05:26 -1 for basically the same reasons as jwb 19:05:41 I am +1 to the general idea. 19:05:55 Because there was atleast one example where time could have helped. 19:05:57 1) The s/gnome-packagekit/gnome-software/ in critical path definition seems an obvious update 19:05:59 Proposal: approve this part 19:06:13 that part is ok with me 19:06:23 mitr: +1 for the text change, yeah 19:06:37 #agreed Increasing the time spent in testing was rejected (-5) 19:06:41 kparal had an alternative suggestion, to require all critpath packages to spend two weeks in testing regardless of karma, and not treat updates differently at all. 19:06:52 *update-related packages 19:07:21 there are many packages stuck in updates testing forever 19:07:21 That's crazy. 19:07:26 More votes on the critical path definition, please? We should talk about other ideas but let’s get that vote out of the way. 19:07:35 update timeouts are for code you can't test programmaticaly 19:07:43 mitr: Yes +1 to s/gnome-packagekit/gnome-software/ 19:07:57 changing the length of time spent in testing is not a solution for this problem, which is clearly amenable to programmatic testing 19:07:58 moezroy: What packages are those? 19:08:35 rishi, packages where the maintainer forgot to push it to stable. 19:09:11 mitr, +1 s/gnome-packagekit/gnome-software/ in critical path definition 19:09:17 #agreed Replacing gnome-packagekit by gnome-software in critical path definition has been approved (+5) 19:10:15 Correction: kparal did not propose two weeks, he proposed "a certain minimal amount of time" 19:10:17 moezroy: That is a bit lousy on the side of the maintainer, I would say. 19:10:21 ajax: Yeah, this is clearly something for software to test automatically. Now only to get this happen… 19:10:29 And we are talking about a specific subset of packages here. 19:10:51 moezroy: And don't we have a mechanism to auto-push to stable now? 19:11:01 I have certainly seen that happen for a few of my updates. 19:11:11 Lacking that, it seems to me that just gently asking the librepo maintainer to test offline updates before pushing the package to testing could work; this is not “the world is breaking offline updates”, this is specifically librepo/libhif. 19:11:16 mitr: Nobody will write these tests I think, so updates will break again sooner or later. :( I mean, by necessity the test must reboot the computer, that's not trivial to automate.... 19:11:31 it is literally trivial to automate 19:11:39 you don't reboot a computer, you reboot an OS instance 19:11:46 mcatanzaro: This test would be like the #2 on the tests one would ever write for Fedora updates; if nobody will write this one we are doomed DOOMED. 19:11:50 mitr: That is true, the problem is really those two packages specifically. We'd rather they not be updated at all. 19:12:08 that tends to not work out over the life of a release 19:12:19 mostly because nothing is perfect and there are bugs and security issues 19:12:24 jwb: Yeah, hence I didn't propose it ^^ 19:12:37 i like the idea of adversarial automatic testing 19:12:57 where gnome-software would write the qa tests for librepo that could programmatically reject an update 19:13:00 why isn't that how it works? 19:13:12 mcatanzaro: Saying that they should never be updates is a bit too extreme. 19:13:39 ajax: Not enough people paid to QA, I think. 19:14:09 Let me see if I can get some gnome-software maintainer in here. 19:14:17 Just pinged kalev 19:14:18 rishi, a little off-topic but it wont auto push to stable (even though time spent has passed - 7 days/14 days for epel) if there is not enough karma. 19:14:30 rhughes said "This 100% has my vote. I'm sick and tired of offline updates breaking." in the ticket 19:14:54 His family is sick today fwiw 19:15:13 seriously though, is autoqa not a thing 19:15:17 still 19:15:20 ajax: Don’t know, let’s find out? 19:15:22 Proposal: 1) Ask librepo maintainer to test off-line updates before pushing any updates. 2) Recommend gnome-software maintainers to write automated tests for their tests. 19:15:28 ajax: Not any more, taskotron is the word of the year. 19:15:55 mitr: ah, much more future-y, i approve 19:16:05 ajax: And this does seem like an appropriate starting point to its wider adoption. 19:16:26 mitr: exactly. we shouldn't be writing policy like this if we have mechanism to get there already. 19:16:28 … “for their update mechanism”, not tests for tests obviously. 19:16:38 mitr, +1 19:16:39 mitr: +1 to that proposal 19:16:43 * mitr is 1) +1 2) +1 19:17:02 +1 to proposal 19:17:05 Unofficial +1 from me, I suppose. 19:17:26 +1 19:17:48 Or at least +0, it's a reasonable resolution 19:17:50 * rishi would like to get some dinner soon :) 19:17:52 #agreed 1) Ask librepo maintainer to test off-line updates before pushing any updates. 2) Recommend gnome-software maintainers to write automated tests for their update mechanism (+5) 19:17:59 mitr: +1 19:18:03 late... :-/ 19:18:07 #undo 19:18:07 Removing item from minutes: AGREED by mitr at 19:17:52 : 1) Ask librepo maintainer to test off-line updates before pushing any updates. 2) Recommend gnome-software maintainers to write automated tests for their update mechanism (+5) 19:18:13 #agreed 1) Ask librepo maintainer to test off-line updates before pushing any updates. 2) Recommend gnome-software maintainers to write automated tests for their update mechanism (+6) 19:18:15 #topic #1411 F21 privacy issue, Geolocation done for every install 19:18:17 .fesco 1411 19:18:18 mitr: #1411 (F21 privacy issue, Geolocation done for every install) – FESCo - https://fedorahosted.org/fesco/ticket/1411 19:18:19 https://fedorahosted.org/fesco/ticket/1411 19:19:05 i'm still confused how this is a privacy issue 19:19:05 Technically, the default seems to be a https request to a Fedora server, i.e. not disclosing anything the post-boot PackageKit/dnf repo sync won’t disclose. 19:19:39 Though, to me, this is really a matter of 1) what our privacy policy says, 2) how do users agree to it, and 3) what are the legal requirements that apply to 1) and 2) 19:20:07 i.e. it seems to me we need Fedora legal to lead this discussion. 19:20:53 mitr: i think the point is, that post-boot sync doesn't ever happen in the threat model considered 19:21:02 jwb: I see some case for software showing you your location when you don’t want the software to track your activity being a surprise/annoyance. 19:21:15 ajax: Does the user have a practical method to prevent the post-boot sync at all? 19:21:24 I don't mind the status quo, since it is not worse than what other components are doing. eg., no GUI way to turn off updates checking. 19:21:44 mitr: eh, maybe if deconfiguring the network is still a thing you can do from the anaconda ui 19:22:08 but i guess think "i need to install an OS and i don't trust the government of the country i'm in" 19:22:09 Anaconda has a way to turn it off, just like anything else. 19:22:29 in a GUI install it's already done the geoloc by the time you get a chance to turn it off. this seems awfully storm-in-teacup-y to me, though. 19:22:44 rishi: Opt-outs generally don’t work. 19:22:52 it's a geoip lookup, it's not like it's reading your frickin' GPS. 19:23:28 For context, there was a recent discussion to reveal the various knobs in GNOME (checking for updates, NM captive portal, geolocation) in a more visible way to the user. Possibly in initial-setup. 19:23:30 adamw: There actually _is_ code there to geolocate you using Wifi, asking Google for your location and then translating it into a city. But it’s not used by default (and hard-coded in constants.py) 19:23:36 mitr, but anaconda is already going to hit the same servers during an install because it defaults to updates enabled. 19:23:47 mitr: Agree, but we can not just blame Anaconda here. 19:24:00 It is not worse than say the NM captive portal pings. 19:24:05 jwb: Yeah, it is a “surprise” (user comfort) issue, not technically different 19:24:08 Or gnome-software checking for updates. 19:24:19 rishi: Blame is really not at all a question. 19:24:29 SURPRISE! I'M CONTACTING THE DISTRO SERVERS TO INSTALL YOUR OS! isn't much of a surprise 19:24:40 mitr: Well the ticket specifically points out Anaconda. 19:24:51 I think we should have a privacy policy and get all the various components to obey it. 19:25:01 Proposal: Cc: spot for fedora-legal to see whether there is any issue or whether we need to update privacy policy. 19:25:11 realistically it seems to me we have a choice to be a more-or-less sane for typical use distro, or to try and be tails. i mean, if you start diving down this rabbit hole, where do you end? 19:25:15 mitr: +1 19:25:21 (Alternative proposal would be just to close the ticket as “not doing anything worth worrying about”) 19:25:58 mitr: Another alternative would be to have Anaconda make this clear to the user. 19:26:05 adamw: ISTM it would be fairly reasonable to guess the country locale from the language (or the other way) instead of relying on geoip; preventing this lookup would be by no means a disaster. 19:26:12 That it is pinging a server. A boot option is a bit arcane. 19:26:16 rishi: At that point it would be easier not to have the automation at all in there. 19:26:54 rishi: I don't think it makes sense to interrupt the user to inform that anaconda will do geoip, when it's only being used to pick a default for one option (so the user isn't "interrupted" to change the option). There is no other benefit to the geoip.... 19:27:07 mitr: iirc the geoip is mainly to get a timezone, which is pretty convenient. 19:27:49 adamw: Good point. I live in a small country which makes the (language,country)->TZ translation trivial 19:28:19 trying to guess anything from 'English' is a bit tricky. :P 19:29:24 mcatanzaro: mitr: Yeah, that was my take away from talking to the Anaconda guys at DevConf. 19:29:38 But it was a quick one, so didn't get a chance to explore every option. 19:29:58 I don't know. I guess if you are really paranoid, then you will just unplug the cable and not connect to Wifi. 19:30:08 so anyway 19:30:36 * rishi repeats that would like to get some dinner soon :) 19:30:37 the default is sort of irrelevant since there's a command line toggle already, right? products get to define their own kickstarts 19:31:02 More votes on asking spot? Other proposals? 19:31:05 and everything else is anaconda ui change 19:31:13 ajax, good point 19:31:15 which isn't necessarily ours to mandate 19:31:29 so yes i would like an idea of what our baseline privacy policy should be 19:31:40 because that would help define how a tails-like fedora would need to vary 19:31:57 but i'm not sure the ticket itself is much to act on 19:32:01 ajax: Punting this to products would’t AFAICS solve anything, there is nothing product-specific that would help them in this decision. 19:32:50 mitr: servers aren't set up to point to local ntp strata? workstation doesn't want to just Get It Right like osx? 19:33:02 mitr, but there is no _generic_ kickstart to turn if off in. so it is by definition product specific 19:33:13 ajax: Yes, good point. 19:33:20 i suppose that isn't quite true. most inherit from a set of common kickstarts 19:33:44 mitr: I am +1 for asking spot if you are putting it to the vote. 19:33:49 but yeah +1 spot 19:33:56 mitr, +1 to consult fedora-legal 19:34:14 ajax: By saying workstation could "get it right" you are implying that there is an obvious “right”, wouldn’t it apply to everything else equally? 19:34:37 #agreed Cc: spot for fedora-legal to see whether there is any issue or whether we need to update privacy policy (+5) 19:34:47 #topic #1269 Closing all 'Merge Review' bugs 19:34:49 .fesco 1269 19:34:51 mitr: #1269 (Closing all 'Merge Review' bugs) – FESCo - https://fedorahosted.org/fesco/ticket/1269 19:34:51 https://fedorahosted.org/fesco/ticket/1269 19:34:53 Kevin was +1 to reassigning all these bugs to the component owners, for them to handle as they wish. 19:34:58 crobinso: ^^^ 19:35:06 mitr: yep, I'm here 19:35:07 +1 19:35:11 Yes, +1 19:35:56 mitr: fine, pretend i said "zeroconf" 19:36:35 -1 to close them 19:36:48 that wasn't the proposal 19:37:04 I have seen many of them are not following current packaging guidelines 19:37:14 +1 I guess. I don’t think the bugs just should be closed because they are still outstanding action item, and we have no reason to think they have been fixed in the meantime (like we are sort of hoping for the mass closures); OTOH having them in the review queue when obviously nobody is interested in reviewing them is not helping either, so assigning them to the component owners is close enough to the ideal. 19:37:26 paragan: have you read the minutes from the last meeting we discussed this? we've been over that already 19:38:03 I'm +1 for reassigning to components 19:38:09 crobinso, I just read ticket 19:38:24 +1 reassign to components 19:38:44 Merge reviews are open since many years. If we conclude here that move component of those bugs from "Package Review" to their own component and leave it's closing/reviewing to package maintainers then I don't see any benefit of having discussion here. 19:38:50 they will remain unattended 19:39:15 and? 19:39:17 paragan: This might actually help because they will now show up on the package maintainer’s bug list. (one of them anyway) 19:39:19 which can be no worse than the status quo 19:39:29 because they are now already unattended 19:39:46 and if they close it as NOTABUG or WONTFIX then 19:39:58 then it still is no different than the status quo 19:40:15 the bug will still be there regardless of whether the bugzilla tracks it 19:40:18 Also, there is nothing stopping a packager from doing something crazy after the package review. But I guess that is a fight for another day :/ 19:40:22 Guys, I am really sorry, but I need to run now. I think we have already covered all the things that I could have knowledgeably voted on. 19:40:22 I will prefer to allow provenpackagers to fix those packages 19:40:34 paragan: they already are allowed to 19:40:35 paragan, they have been able to do so for 8 damn years 19:40:38 #agreed Reassign all merge reviews to their component, version=rawhide, with the comment in https://fedorahosted.org/fesco/ticket/1269#comment:16 (+5-1) 19:40:55 * rishi -> AFK (sorry about this) 19:41:01 Who can actually mass-edit and reassign the bugs? 19:41:06 mitr: I can do it 19:41:11 Great 19:41:19 #action crobinso to mass-edit and reassign the bugs 19:41:28 #topic #1326 change to fesco replacement process? 19:41:30 .fesco 1326 19:41:32 https://fedorahosted.org/fesco/ticket/1326 19:41:32 mitr: #1326 (change to fesco replacement process?) – FESCo - https://fedorahosted.org/fesco/ticket/1326 19:41:35 i propose we defer this 19:41:55 it's not clear to me we have 1) the participants necessary 2) any actual new proposal 19:42:34 I’m tempted to just close this because we haven’t been making progress and are essentially solving a hypothetical, but deferring a week to allow the new FESCo members to form an opinion makes sense. 19:42:42 I agree. This ticket seems to be going nowhere 19:42:44 +1 to deferring 19:43:04 +1 for deferring or closing 19:43:54 +1 defer, but from a quick readthrough my opinion is probably going to be "close, no new proposal" 19:44:49 At +4, so I guess 19:44:53 +1 for closing 19:44:53 #info deferred 19:45:39 Note: I'm afraid I have missed adding the meeting keyword to #1412 (anaconda password complexity discussion), so let’s defer it to the next week. 19:45:57 #topic Next week's chair 19:45:59 Who wants to chair the meeting next week? 19:46:30 i can 19:46:41 #info jwb will chair next week’s meeting 19:46:46 all yours buddy 19:46:46 #topic Open Floor 19:46:51 Any more topics to discuss? 19:47:05 none from me 19:47:17 If not, will close the meeting at xx:49 19:49:22 Thanks, everyone! 19:49:24 #endmeeting