18:00:17 <mitr> #startmeeting FESCO (2015-02-11)
18:00:17 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:19 <mitr> #meetingname fesco
18:00:19 <zodbot> The meeting name has been set to 'fesco'
18:00:21 <mitr> #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh
18:00:21 <zodbot> Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza
18:00:23 <mitr> #topic init process
18:00:25 <mitr> Hello everyone
18:00:42 <paragan> Hi
18:00:44 * rishi waves
18:00:54 * crobinso is here for merge review discussion
18:01:13 <ajax> hey
18:01:21 <jwb> hellos
18:01:30 <mitr> crobinso: (Because of the number of tickets that one is next to last on the agenda)
18:01:39 <jwb> CLOSE THEM ALREADY
18:01:42 * jreznik is here in case fesco would need him, ready to server
18:01:54 <jwb> jreznik, you should be ready to workstation too ;)
18:01:55 * mattdm is lurking
18:02:04 <crobinso> mitr: okay, someone ping me if he comes up please, I suck at IRC
18:02:11 <crobinso> s/he/it/
18:02:32 <jreznik> jwb: ah :) and +1 to previous one, close them all
18:02:36 <ajax> jwb: merge reviews are the new 998
18:02:49 <jwb> ajax, they are entirely worse, but i see what you're getting at
18:03:18 <rishi> +1 to closing merge reviews
18:03:28 <thozza> hi all
18:04:42 <mitr> That’s 6, sgallagh_afk is afk, nirik wrote that he will likely not be able to attend, let’s start.
18:04:47 <mitr> #topic Welcoming new FESCo members
18:04:57 <mitr> New FESCo members, welcome!  Departing FESCo members, thank you!
18:05:34 <mitr> Is there any related administrative work outstanding?  e.g. fesco list membership
18:05:45 <ajax> it's good to be back, i suppose
18:06:00 <thozza> are we going to change the time for FESCo meeting? or are we going to keep the current time?
18:06:32 <moezroy> thozza, to saturday's?
18:06:45 <mitr> Checking won’t hurt.
18:06:49 <ajax> i don't have much of a preference about time
18:06:58 <ajax> so whatever works
18:07:17 <mitr> #action mitr to send a whenisgood form, results to be discussed on the next meeting
18:07:28 <thozza> moezroy: I was thinking about sunday
18:07:44 <thozza> ;)
18:08:11 <mitr> So, the mailing list—new members, are you on https://lists.fedoraproject.org/mailman/listinfo/fesco ?  If not, please subscribe.
18:08:33 <rishi> mitr: Yes, I already subscribed last week. nirik let me in.
18:08:34 <mitr> 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 <mitr> #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 <mitr> .fesco 1384
18:08:48 <zodbot> 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 <mitr> https://fedorahosted.org/fesco/ticket/1384
18:08:50 <mitr> 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 <jwb> same
18:09:18 <ajax> i mean, i guess
18:09:19 <mitr> (The change has been updated for F23 in the mean time).
18:09:38 <ajax> 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 <mitr> 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 <paragan> +1 from me as well
18:10:25 <ajax> +1
18:10:48 <jwb> +1 if i wasn't clear before
18:11:18 <mitr> #agreed F23 System Wide Change: Harden all packages with position-independent code approved (+5)
18:11:22 <rishi> +1 from me too.
18:11:32 <moezroy> thank you!
18:11:34 <mitr> #undo
18:11:34 <zodbot> 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 <mitr> #agreed F23 System Wide Change: Harden all packages with position-independent code approved (+5)
18:12:38 <mitr> 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 <jreznik> mitr: sure, it's not something we have to talk about now
18:13:20 <mitr> I think we can deal with these three tickets as a block:
18:13:25 <mitr> #topic #1390 F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades - https://fedoraproject.org/wiki/Changes/RpmOstree
18:13:27 <mitr> .fesco 1390
18:13:28 <zodbot> 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 <mitr> https://fedorahosted.org/fesco/ticket/1390
18:13:31 <mitr> #topic #1396 F22 System Wide Change: Atomic Host - https://fedoraproject.org/wiki/Changes/AtomicHost
18:13:33 <mitr> .fesco 1396
18:13:35 <mitr> https://fedorahosted.org/fesco/ticket/1396
18:13:35 <zodbot> mitr: #1396 (F22 System Wide Change: Atomic Host - https://fedoraproject.org/wiki/Changes/AtomicHost) – FESCo - https://fedorahosted.org/fesco/ticket/1396
18:13:40 <mitr> #topic #1397 F22 System Wide Change: Bare Metal Installer for Fedora Atomic Host - https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic
18:13:43 <mitr> .fesco 1397
18:13:44 <zodbot> 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 <mitr> https://fedorahosted.org/fesco/ticket/1397
18:13:46 <mitr> Proposal: Defer tickets 1390, 1396, 1397 until we get more specifics, remove meeting keyword until then.
18:13:55 <jwb> yeah, +1.
18:14:05 <jwb> that was all supposed to happen already, but i guess it didn't
18:14:16 <ajax> fine with me, +1
18:14:22 <paragan> right +1 to defer
18:14:23 <thozza> mitr: +1
18:14:33 <ajax> i'd like more time to read into the atomic stuff regardless
18:14:51 <jwb> it's full of files and hardlinks.
18:14:57 <rishi> +1, looks like they have got the patches into Anaconda.
18:15:17 <mitr> #agreed Defer tickets 1390, 1396, 1397 until we get more specifics, remove meeting keyword until then (+6)
18:15:31 <mitr> #topic #1392 Review scope of "Python 3 as default" Change for F22
18:15:33 <mitr> .fesco 1392
18:15:34 <zodbot> mitr: #1392 (Review scope of "Python 3 as default" Change for F22) – FESCo - https://fedorahosted.org/fesco/ticket/1392
18:15:35 <mitr> https://fedorahosted.org/fesco/ticket/1392
18:15:37 <mitr> 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 <jwb> sure
18:16:17 <ajax> if there are two places we're talking about this, yes, let's have only one
18:16:22 <rishi> I am a bit clueless about Python. :/
18:16:55 <paragan> Can it be moved to target F23 or we will ask new ticket for it?
18:17:05 <jwb> rishi, there's lots of time to learn :)
18:17:20 <jreznik> it should be moved to F23
18:17:25 <thozza> mitr: +1 sure
18:17:26 <mitr> 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 <rishi> jwb: I hope I am never encounter one in real life. :-P
18:17:36 <jreznik> mitr: exactly
18:17:36 <rishi> (damn, I can't type)
18:17:47 <jwb> heh
18:18:07 <jreznik> and for this Change I'd like to avoid moving to F23 automatically, it's more for next release review...
18:18:25 <paragan> ok then +1 to close ticket
18:18:27 <mitr> #agreed Close this ticket, discuss the specifics in #1413 instead.  (+5)
18:18:35 <mitr> Speaking of which, …
18:18:44 <mitr> #topic #1413 F22 System Wide Change: Python 3 Migration Improvements - https://fedoraproject.org/wiki/Changes/Python_3_Migration_Improvements
18:18:46 <mitr> .fesco 1413
18:18:47 <zodbot> 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 <mitr> https://fedorahosted.org/fesco/ticket/1413
18:18:50 <mitr> Kevin was +1 in the ticket.
18:19:19 <jwb> +1
18:19:21 <mitr> 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 <paragan> +1
18:20:45 <thozza> +1
18:21:03 <ajax> +1
18:21:11 <mitr> #agreed F22 System Wide Change: Python 3 Migration Improvements has been accepted (+6)
18:21:20 <mitr> #topic #1406 F22 System Wide Change: Systemd Package Split - https://fedoraproject.org/wiki/Changes/SystemdPackageSplit
18:21:22 <mitr> .fesco 1406
18:21:23 <zodbot> 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 <mitr> https://fedorahosted.org/fesco/ticket/1406
18:22:01 * zbyszek is here
18:22:04 <rishi> -1 from me, since both Lennart and Kay were clearly against it.
18:22:07 <mitr> I am +1; the existence of fakesystemd is another reason why this is needed.
18:22:40 <jwb> ooh, a non-unanimous vote
18:22:46 <jwb> and i'm all out of popcorn
18:22:46 <ajax> rishi: i'm sorry, where was that expressed?
18:23:00 <rishi> ajax: https://lists.fedoraproject.org/pipermail/devel/2015-January/206889.html
18:23:06 <mitr> ajax: In the fedora-devel thread; essentially saying that systemd API is a package deal.
18:23:07 <rishi> and https://lists.fedoraproject.org/pipermail/devel/2015-January/206984.html
18:24:01 <ajax> thanks
18:24:09 <rishi> zbyszek: Will the systemd-filesystem idea work for you?
18:24:14 <mitr> IMHO this is clearly an improvement; As the last time, I could go with “+1 but does not override package owners”
18:24:27 <zbyszek> rishi: No.
18:24:30 <mitr> rishi: That doesn’t work; other packages’ scriptlets depend on running systemctl
18:25:02 <ajax> mitr: do they depend on it working, though
18:25:27 <mitr> ajax: In the single-process-container scenario, no.
18:26:02 <mitr> (This is where we could go into an extensive detour into whether this scenario is desirable or not.)
18:26:54 <zbyszek> 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 <mitr> zbyszek: Ah, sorry.  Thanks for setting me straight.
18:28:09 <zbyszek> With a hypothetical -filesystem package, enable/disable/presets would be lost.
18:29:43 <ajax> are allowed to redundantly package files?
18:29:49 <ajax> are we, even
18:30:20 <mitr> ajax: “redundantly”?
18:30:32 <thozza> ajax: if those files are the same it should not be a problem IMHO
18:30:43 <ajax> mitr: same content at the same path, in multiple subpackages of a single srpm
18:31:22 <mitr> 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 <zbyszek> mitr: we are talking about a strictly limited set of calls found in rpm macros, as prescribed by the packaging guidelines.
18:32:35 <rdieter> ajax: yes, that's allowed
18:33:29 <thozza> 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 <thozza> so count me +1 for it
18:33:38 <mitr> More votes?  Questions?  Concerns?
18:33:53 <ajax> i mean, nothing's forever
18:34:16 <jwb> +0
18:34:17 <ajax> i think i see what kay/lennart are getting at but i'm not convinced
18:34:35 <rishi> 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 <ajax> 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 <mitr> So we are at +3-1 1x0  and apparently no way to get this approved/rejected.
18:35:27 <mcatanzaro> rishi: zbyszek is one of the downstream owners: http://pkgs.fedoraproject.org/cgit/systemd.git/
18:35:50 <zbyszek> I'm also upstream, fwiw :)
18:35:52 <thozza> rishi: kay and lennart are not really the owners I think
18:35:55 <mitr> 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 <thozza> rishi: zbyszek seems to be doing most of the stuff in Fedora WRT systemd
18:36:11 <mitr> thozza: They are committers, like quite a few other people.
18:36:22 <thozza> mitr: sure, but not the only owners
18:36:40 <rishi> zbyszek: So, I guess you can convince Lennart and Kay, right? :)
18:36:51 <rishi> Did you talk to them outside devel@lists.fp.o ?
18:37:02 <mitr> 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 <zbyszek> rishi: Yes, I talked to them, and they are against. I don't think this will change.
18:37:43 <mitr> We are at 15 minutes, discuss more or move on?
18:37:55 <rishi> 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 <ajax> if it produces an os that works by all available metrics, then i don't see how fesco can object
18:38:21 <thozza> ajax: right
18:38:24 <ajax> are we concerned about being impolitic or are we concerned about the quality of work
18:39:11 <ajax> 'cause i'm pretty sure fesco is primarily not meant to be about diplimacy
18:39:13 <mitr> 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 <mitr> #info No conclusion reached (+3 -1 1×0), will discuss next week
18:40:11 <mitr> #topic #1377 enable kdump addon by default
18:40:14 <mitr> .fesco 1377
18:40:15 <mitr> https://fedorahosted.org/fesco/ticket/1377
18:40:15 <zodbot> mitr: #1377 (enable kdump addon by default) – FESCo - https://fedorahosted.org/fesco/ticket/1377
18:41:07 <rishi> -1 to enabling it by default on all systems, since the Fedora kernel team is against it.
18:41:24 <mitr> It seems undisputed that there are frequent hardware driver problems, so -1.
18:41:40 <ajax> this would be a product question not a fedora question, right?
18:41:45 <mitr> 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 <jwb> ajax, that's a possibility.  i don't think the ticket was raised that way though
18:42:04 <mitr> ajax: Why would products differ in this decision?  Because they implicitly mean different hardware?
18:42:40 <ajax> mitr: somewhat yeah.  i mean, if the drm support isn't functional, kdump isn't useful for workstation.
18:42:46 <jwb> i would probably still object on a per product basis though, since none of the products actually have hardware requirements/specifications
18:43:26 <thozza> that is true, all are built for all primary architectures...
18:44:07 <mitr> 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 <jwb> uh, what?
18:44:41 <jwb> kdump isn't for getting backtraces
18:44:50 <jwb> it's like core files for the kernel
18:45:07 <jwb> ABRT gets backtraces just fine in a large majority of cases
18:45:32 <mitr> backtraces/minidumps/… Sorry, this comment was really irrelevant for the decision at hand anyway.
18:46:06 <jwb> 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 <jwb> spend a while getting it working, just to get back to the point of seeing 8000 intel WARN_ONs?  nah :)
18:46:57 <ajax> yeah i'm leaning -1 here
18:47:05 <thozza> -1
18:47:07 <paragan> -1 we don't need it default enabled.
18:47:34 <mitr> 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 <jwb> it needs a serial port
18:48:35 <jwb> virt guests have other ways to get debug data.  i don't think kdump is relevant there
18:49:06 <jwb> basically, translate it to "physical hardware you would install RHEL on"
18:49:18 <mitr> ajax: Is that a vote?
18:49:46 <ajax> yes
18:49:52 <mitr> #agreed Enabling the kdump addon by default was rejected (-5)
18:50:04 <mitr> #topic #1408 New package/branch request processes (off bugzilla to pkgdb)
18:50:06 <mitr> .fesco 1408
18:50:08 <mitr> https://fedorahosted.org/fesco/ticket/1408
18:50:08 <zodbot> mitr: #1408 (New package/branch request processes (off bugzilla to pkgdb)) – FESCo - https://fedorahosted.org/fesco/ticket/1408
18:50:10 <mitr> Kevin supported the 7-day waiting period in the ticket.
18:50:35 <ajax> sounds fine to me too
18:51:01 <jwb> +1
18:51:12 <mitr> 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 <ajax> mitr: that's my impression as well.
18:51:56 <paragan> +1
18:52:12 <tibbs|w> I have had an unwanted branch applied, but that was a long time ago.
18:52:17 <mitr> 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 <tibbs|w> 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 <tibbs|w> 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 <mitr> 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 <mitr> I guess I’ll go with the majority, and counting ajax as +1 (right?) that gets us to +5.
18:54:48 <ajax> mitr: yes
18:54:50 <tibbs|w> 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 <mitr> #agreed     Implement a similar waiting period for Fedora branch as we do for EPEL branch (+5)
18:55:28 <mitr> #topic #1409 provenpackager request: mstuchli
18:55:30 <mitr> .fesco 1409
18:55:32 <zodbot> mitr: #1409 (provenpackager request: mstuchli) – FESCo - https://fedorahosted.org/fesco/ticket/1409
18:55:32 <mitr> https://fedorahosted.org/fesco/ticket/1409
18:55:34 <mitr> 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 <mitr> Kevin, in the ticket, supports automatic refusal of provenpackager requests if there are no votes.
18:55:46 <tibbs|w> Kind of surprised the cvsadmins wheren't CC'd on 1408, honestly.
18:56:00 <jwb> i think so
18:56:21 <rishi> Just repeating my +1. He seems to have the confidence of the people he works with. So no reason to object.
18:56:31 <ajax> +1
18:56:43 <thozza> mitr: I'm also +1
18:56:55 <tibbs|w> Is it possible to actually CC the packager-sponsors list/alias on those tickets?
18:56:56 <mitr> Assuming all the votes above are for him becoming provenpackager?
18:57:11 <thozza> mine is :)
18:57:16 <rishi> So was mine. :)
18:57:23 <ajax> 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 <ajax> just all the affirmatives
18:57:35 <tibbs|w> I know Kevin sends one message to the list but it might be nice to see the updates as well.
18:57:36 <paragan> Based on the information provided for Matej, I will +1
18:57:39 <mitr> Yeah, mstuchli becoming a provenpackager is AFAICS a done deal.
18:58:41 <mitr> 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 <mitr> 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 <ajax> hah
19:00:15 <ajax> yeah that's odd
19:00:28 <mitr> So,
19:00:30 <mitr> 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 <ajax> mitr: +1
19:01:01 * mitr is +1 for the record
19:01:42 <thozza> +1
19:01:46 <rishi> +1
19:02:14 <paragan> +1
19:02:48 <mitr> #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 <mitr> #topic #1410 Updates Policy should try harder to prevent updates that break future updates
19:03:04 <mitr> .fesco 1410
19:03:06 <mitr> https://fedorahosted.org/fesco/ticket/1410
19:03:06 <zodbot> mitr: #1410 (Updates Policy should try harder to prevent updates that break future updates) – FESCo - https://fedorahosted.org/fesco/ticket/1410
19:03:08 <mitr> Kevin was -1 in the ticket.
19:04:00 <rishi> I found the bit about "all updates must be in the form of individual patches" to be a little extreme. :)
19:04:01 <jwb> -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 <paragan> -1 to increase more time in testing
19:04:37 <mcatanzaro> rishi: In other distros, that is normal, but it's a detail and I don't mind details too much.
19:05:08 <mitr> -1 to the proposal as written.  OTOH.
19:05:08 <mcatanzaro> But I think if we don't increase time in testing, we are just going to keep breaking updates.
19:05:08 <rishi> mcatanzaro: Yeah
19:05:26 <ajax> -1 for basically the same reasons as jwb
19:05:41 <rishi> I am +1 to the general idea.
19:05:55 <rishi> Because there was atleast one example where time could have helped.
19:05:57 <mitr> 1) The s/gnome-packagekit/gnome-software/ in critical path definition seems an obvious update
19:05:59 <mitr> Proposal: approve this part
19:06:13 <jwb> that part is ok with me
19:06:23 <ajax> mitr: +1 for the text change, yeah
19:06:37 <mitr> #agreed Increasing the time spent in testing was rejected (-5)
19:06:41 <mcatanzaro> 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 <mcatanzaro> *update-related packages
19:07:21 <moezroy> there are many packages stuck in updates testing forever
19:07:21 <zbyszek> That's crazy.
19:07:26 <mitr> 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 <ajax> update timeouts are for code you can't test programmaticaly
19:07:43 <rishi> mitr: Yes +1 to s/gnome-packagekit/gnome-software/
19:07:57 <ajax> 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 <rishi> moezroy: What packages are those?
19:08:35 <moezroy> rishi, packages where the maintainer forgot to push it to stable.
19:09:11 <paragan> mitr, +1  s/gnome-packagekit/gnome-software/ in critical path definition
19:09:17 <mitr> #agreed Replacing gnome-packagekit by gnome-software in critical path definition has been approved (+5)
19:10:15 <mcatanzaro> Correction: kparal did not propose two weeks, he proposed "a certain minimal amount of time"
19:10:17 <rishi> moezroy: That is a bit lousy on the side of the maintainer, I would say.
19:10:21 <mitr> ajax: Yeah, this is clearly something for software to test automatically.  Now only to get this happen…
19:10:29 <rishi> And we are talking about a specific subset of packages here.
19:10:51 <rishi> moezroy: And don't we have a mechanism to auto-push to stable now?
19:11:01 <rishi> I have certainly seen that happen for a few of my updates.
19:11:11 <mitr> 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 <mcatanzaro> 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 <ajax> it is literally trivial to automate
19:11:39 <ajax> you don't reboot a computer, you reboot an OS instance
19:11:46 <mitr> 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 <mcatanzaro> mitr: That is true, the problem is really those two packages specifically. We'd rather they not be updated at all.
19:12:08 <jwb> that tends to not work out over the life of a release
19:12:19 <jwb> mostly because nothing is perfect and there are bugs and security issues
19:12:24 <mcatanzaro> jwb: Yeah, hence I didn't propose it ^^
19:12:37 <ajax> i like the idea of adversarial automatic testing
19:12:57 <ajax> where gnome-software would write the qa tests for librepo that could programmatically reject an update
19:13:00 <ajax> why isn't that how it works?
19:13:12 <rishi> mcatanzaro: Saying that they should never be updates is a bit too extreme.
19:13:39 <mcatanzaro> ajax: Not enough people paid to QA, I think.
19:14:09 <rishi> Let me see if I can get some gnome-software maintainer in here.
19:14:17 <rishi> Just pinged kalev
19:14:18 <moezroy> 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 <mcatanzaro> rhughes said "This 100% has my vote. I'm sick and tired of offline updates breaking." in the ticket
19:14:54 <mcatanzaro> His family is sick today fwiw
19:15:13 <ajax> seriously though, is autoqa not a thing
19:15:17 <ajax> still
19:15:20 <mitr> ajax: Don’t know, let’s find out?
19:15:22 <mitr> 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 <mitr> ajax: Not any more, taskotron is the word of the year.
19:15:55 <ajax> mitr: ah, much more future-y, i approve
19:16:05 <mitr> ajax: And this does seem like an appropriate starting point to its wider adoption.
19:16:26 <ajax> mitr: exactly.  we shouldn't be writing policy like this if we have mechanism to get there already.
19:16:28 <mitr> … “for their update mechanism”, not tests for tests obviously.
19:16:38 <jwb> mitr, +1
19:16:39 <ajax> mitr: +1 to that proposal
19:16:43 * mitr is 1) +1 2) +1
19:17:02 <paragan> +1 to proposal
19:17:05 <mcatanzaro> Unofficial +1 from me, I suppose.
19:17:26 <rishi> +1
19:17:48 <mcatanzaro> Or at least +0, it's a reasonable resolution
19:17:50 * rishi would like to get some dinner soon :)
19:17:52 <mitr> #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 <thozza> mitr: +1
19:18:03 <thozza> late... :-/
19:18:07 <mitr> #undo
19:18:07 <zodbot> 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 <mitr> #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 <mitr> #topic #1411 F21 privacy issue, Geolocation done for every install
19:18:17 <mitr> .fesco 1411
19:18:18 <zodbot> mitr: #1411 (F21 privacy issue, Geolocation done for every install) – FESCo - https://fedorahosted.org/fesco/ticket/1411
19:18:19 <mitr> https://fedorahosted.org/fesco/ticket/1411
19:19:05 <jwb> i'm still confused how this is a privacy issue
19:19:05 <mitr> 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 <mitr> 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 <mitr> i.e. it seems to me we need Fedora legal to lead this discussion.
19:20:53 <ajax> mitr: i think the point is, that post-boot sync doesn't ever happen in the threat model considered
19:21:02 <mitr> 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 <mitr> ajax: Does the user have a practical method to prevent the post-boot sync at all?
19:21:24 <rishi> 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 <ajax> mitr: eh, maybe if deconfiguring the network is still a thing you can do from the anaconda ui
19:22:08 <ajax> 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 <rishi> Anaconda has a way to turn it off, just like anything else.
19:22:29 <adamw> 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 <mitr> rishi: Opt-outs generally don’t work.
19:22:52 <adamw> it's a geoip lookup, it's not like it's reading your frickin' GPS.
19:23:28 <rishi> 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 <mitr> 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 <jwb> mitr, but anaconda is already going to hit the same servers during an install because it defaults to updates enabled.
19:23:47 <rishi> mitr: Agree, but we can not just blame Anaconda here.
19:24:00 <rishi> It is not worse than say the NM captive portal pings.
19:24:05 <mitr> jwb: Yeah, it is a “surprise” (user comfort) issue, not technically different
19:24:08 <rishi> Or gnome-software checking for updates.
19:24:19 <mitr> rishi: Blame is really not at all a question.
19:24:29 <jwb> SURPRISE!  I'M CONTACTING THE DISTRO SERVERS TO INSTALL YOUR OS! isn't much of a surprise
19:24:40 <rishi> mitr: Well the ticket specifically points out Anaconda.
19:24:51 <rishi> I think we should have a privacy policy and get all the various components to obey it.
19:25:01 <mitr> Proposal: Cc: spot for fedora-legal to see whether there is any issue or whether we need to update privacy policy.
19:25:11 <adamw> 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 <thozza> mitr: +1
19:25:21 <mitr> (Alternative proposal would be just to close the ticket as “not doing anything worth worrying about”)
19:25:58 <rishi> mitr: Another alternative would be to have Anaconda make this clear to the user.
19:26:05 <mitr> 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 <rishi> That it is pinging a server. A boot option is a bit arcane.
19:26:16 <mitr> rishi: At that point it would be easier not to have the automation at all in there.
19:26:54 <mcatanzaro> 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 <adamw> mitr: iirc the geoip is mainly to get a timezone, which is pretty convenient.
19:27:49 <mitr> adamw: Good point. I live in a small country which makes the (language,country)->TZ translation trivial
19:28:19 <adamw> trying to guess anything from 'English' is a bit tricky. :P
19:29:24 <rishi> mcatanzaro: mitr: Yeah, that was my take away from talking to the Anaconda guys at DevConf.
19:29:38 <rishi> But it was a quick one, so didn't get a chance to explore every option.
19:29:58 <rishi> 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 <ajax> so anyway
19:30:36 * rishi repeats that would like to get some dinner soon :)
19:30:37 <ajax> 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 <mitr> More votes on asking spot?  Other proposals?
19:31:05 <ajax> and everything else is anaconda ui change
19:31:13 <jwb> ajax, good point
19:31:15 <ajax> which isn't necessarily ours to mandate
19:31:29 <ajax> so yes i would like an idea of what our baseline privacy policy should be
19:31:40 <ajax> because that would help define how a tails-like fedora would need to vary
19:31:57 <ajax> but i'm not sure the ticket itself is much to act on
19:32:01 <mitr> 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 <ajax> 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 <jwb> mitr, but there is no _generic_ kickstart to turn if off in.  so it is by definition product specific
19:33:13 <rishi> ajax: Yes, good point.
19:33:20 <jwb> i suppose that isn't quite true.  most inherit from a set of common kickstarts
19:33:44 <rishi> mitr: I am +1 for asking spot if you are putting it to the vote.
19:33:49 <ajax> but yeah +1 spot
19:33:56 <paragan> mitr, +1 to consult fedora-legal
19:34:14 <mitr> 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 <mitr> #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 <mitr> #topic #1269 Closing all 'Merge Review' bugs
19:34:49 <mitr> .fesco 1269
19:34:51 <zodbot> mitr: #1269 (Closing all 'Merge Review' bugs) – FESCo - https://fedorahosted.org/fesco/ticket/1269
19:34:51 <mitr> https://fedorahosted.org/fesco/ticket/1269
19:34:53 <mitr> Kevin was +1 to reassigning all these bugs to the component owners, for them to handle as they wish.
19:34:58 <mitr> crobinso: ^^^
19:35:06 <crobinso> mitr: yep, I'm here
19:35:07 <jwb> +1
19:35:11 <rishi> Yes, +1
19:35:56 <ajax> mitr: fine, pretend i said "zeroconf"
19:36:35 <paragan> -1 to close them
19:36:48 <jwb> that wasn't the proposal
19:37:04 <paragan> I have seen many of them are not following current packaging guidelines
19:37:14 <mitr> +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 <crobinso> paragan: have you read the minutes from the last meeting we discussed this? we've been over that already
19:38:03 <thozza> I'm +1 for reassigning to components
19:38:09 <paragan> crobinso, I just read ticket
19:38:24 <ajax> +1 reassign to components
19:38:44 <paragan> 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 <paragan> they will remain unattended
19:39:15 <jwb> and?
19:39:17 <mitr> 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 <ajax> which can be no worse than the status quo
19:39:29 <ajax> because they are now already unattended
19:39:46 <paragan> and if they close it as NOTABUG or WONTFIX then
19:39:58 <jwb> then it still is no different than the status quo
19:40:15 <ajax> the bug will still be there regardless of whether the bugzilla tracks it
19:40:18 <rishi> 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 <rishi> 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 <paragan> I will prefer to allow provenpackagers to fix those packages
19:40:34 <ajax> paragan: they already are allowed to
19:40:35 <jwb> paragan, they have been able to do so for 8 damn years
19:40:38 <mitr> #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 <mitr> Who can actually mass-edit and reassign the bugs?
19:41:06 <crobinso> mitr: I can do it
19:41:11 <mitr> Great
19:41:19 <mitr> #action crobinso to mass-edit and reassign the bugs
19:41:28 <mitr> #topic #1326 change to fesco replacement process?
19:41:30 <mitr> .fesco 1326
19:41:32 <mitr> https://fedorahosted.org/fesco/ticket/1326
19:41:32 <zodbot> mitr: #1326 (change to fesco replacement process?) – FESCo - https://fedorahosted.org/fesco/ticket/1326
19:41:35 <jwb> i propose we defer this
19:41:55 <jwb> it's not clear to me we have 1) the participants necessary 2) any actual new proposal
19:42:34 <mitr> 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 <thozza> I agree. This ticket seems to be going nowhere
19:42:44 <mitr> +1 to deferring
19:43:04 <thozza> +1 for deferring or closing
19:43:54 <ajax> +1 defer, but from a quick readthrough my opinion is probably going to be "close, no new proposal"
19:44:49 <mitr> At +4, so I guess
19:44:53 <paragan> +1 for closing
19:44:53 <mitr> #info deferred
19:45:39 <mitr> 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 <mitr> #topic Next week's chair
19:45:59 <mitr> Who wants to chair the meeting next week?
19:46:30 <jwb> i can
19:46:41 <mitr> #info jwb will chair next week’s meeting
19:46:46 <ajax> all yours buddy
19:46:46 <mitr> #topic Open Floor
19:46:51 <mitr> Any more topics to discuss?
19:47:05 <ajax> none from me
19:47:17 <mitr> If not, will close the meeting at xx:49
19:49:22 <mitr> Thanks, everyone!
19:49:24 <mitr> #endmeeting