17:00:27 <nirik> #startmeeting FESCO (2014-07-02)
17:00:27 <zodbot> Meeting started Wed Jul  2 17:00:27 2014 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:27 <nirik> #meetingname fesco
17:00:27 <nirik> #chair abadger1999 dgilmore jwb kylem mattdm mitr mmaslano nirik pjones  sgallagh t8m
17:00:27 <nirik> #topic init process
17:00:27 <zodbot> The meeting name has been set to 'fesco'
17:00:27 <zodbot> Current chairs: abadger1999 dgilmore jwb kylem mattdm mitr mmaslano nirik pjones sgallagh t8m
17:00:32 <pjones> hello.
17:00:41 <sgallagh> .hellomynameis sgallagh
17:00:42 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:01:08 <t8m> hello
17:01:17 <blackbird> szia
17:01:21 <mattdm> .hellowmynameis mattdm
17:01:42 <pjones> .hellowmynameis pjones
17:01:44 <mitr> Hello
17:01:56 <nirik> (no w in hello :)
17:02:03 <pjones> .hellomynameis pjones
17:02:04 <zodbot> pjones: pjones 'Peter Jones' <pjones@redhat.com>
17:02:17 <pjones> yeah, totally works better if we don't copy-pasta eachother's misspelled "hello".
17:02:29 <kylem> morning.
17:02:53 <mattdm> yay!
17:02:54 <nirik> dgilmore / abadger1999 ?
17:03:32 <nirik> ok, we have quorum I guess so we can go ahead and get started.
17:03:39 <nirik> #topic #1178 Fedora 21 scheduling strategy
17:03:40 <nirik> .fesco 1178
17:03:40 <nirik> https://fedorahosted.org/fesco/ticket/1178
17:03:42 <zodbot> nirik: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178
17:03:50 <abadger1999> hola
17:04:01 <nirik> there was a question here brought up by tflink who noticed that we are planning to release f21alpha right before flock.
17:04:19 * mattdm notes that he took benadryl after being stung by a wasp last night, and the brain fog is _just_ starting to wear off
17:04:28 <nirik> mattdm: ouch. ;(
17:04:46 <sgallagh> mattdm: Here, just sign this. No you don't need to read it...
17:04:49 <nirik> so, the question is if we want to adjust the schedule any, or if the day before flock is ok for alpha...
17:04:54 <mattdm> nirik I was more offended than actuallh hurt. I was *just sitting there!*
17:05:10 <nirik> wasps are jerks. :)
17:05:19 <pjones> If it helps, you probably killed the wasp.
17:05:55 <sgallagh> nirik: Assuming we hit our deliverable, I'd *love* to be able to manufacture some Alpha (RC?) liveusb's for Flock
17:06:11 <mattdm> pjones: it flew off and and was buzzing around after. *sigh*
17:06:15 <mattdm> annnyway :)
17:06:29 <sgallagh> But if we do slip, we'll be in blocker-resolution mode DURING the conference
17:06:40 <sgallagh> Which is certainly unfortunate
17:06:43 <nirik> doing alpha then might be a bit painfull for me. I will be traveling to brno that weekend and at brno that mon/tuesday... so not much time around in case there's problems with infrastructure.
17:06:59 <nirik> but it might still be ok.
17:07:12 <mattdm> If releng, qa, and infrastructure think that they can hit the deadline without flock interfering, then it seems actually kind of nice to have the alpha right at the conference
17:07:53 <abadger1999> dgilmore: When are you travelling to flock?
17:08:00 * nirik isn't sure what dgilmore's travel plans are.
17:08:36 <nirik> we are pretty good at boring releases in infrastructure anymore (he says, totally jinxing it)...
17:09:13 <abadger1999> nirik: is that a promise for a non-boring release? ;-)
17:09:19 <nirik> if we hit that date, qa and releng work will be done the week before... and only content syncing to mirrors, bitflipping, etc will need to be done
17:09:32 <sgallagh> abadger1999: I think we can reasonably assume (given Fedora.next) that this will *not* be a boring release :)
17:10:24 <nirik> I'm ok with sticking to the schedule... as long as dgilmore's travels won't cause problems for content seeding/torrent making/etc.
17:10:54 <nirik> shall we just defer this to next week and ask dgilmore ?
17:11:32 <sgallagh> nirik: Different question: does anyone have a current expectation that this date is a bad idea
17:11:50 <sgallagh> If not, let's stick with that date and slip it if rel-eng concerns come up
17:12:01 <sgallagh> (I'm opposed to trying to do it sooner)
17:12:21 <nirik> see tflink's comment.
17:12:31 <nirik> basically the bad idea would be if we slip a week...
17:12:42 <nirik> then everyone is busy trying to fix blockers and being at flock
17:12:59 <mattdm> nirik: yeah, I think that if we do that, we basically have to slip by two weeks.
17:13:13 <sgallagh> Proposal: If an Alpha slip occurs, we make it two weeks to not conflict with Flock
17:13:26 <sgallagh> Let's just say that up-front
17:13:39 <nirik> sure, +1
17:13:48 <kylem> +1
17:13:49 <mitr> +1
17:13:52 <mattdm> +1
17:13:53 <abadger1999> sgallagh: yeah, to  set expectations. +1 to that
17:13:53 * sgallagh is +1 for the record
17:14:07 <pjones> sure, +1
17:14:28 <nirik> #agreed if f21 alpha slips, we will slip 2 weeks to not conflict with flock. (+7,0,0)
17:14:52 <t8m> +1 for the record
17:14:58 <nirik> #undo
17:14:58 <zodbot> Removing item from minutes: AGREED by nirik at 17:14:28 : if f21 alpha slips, we will slip 2 weeks to not conflict with flock. (+7,0,0)
17:15:02 <nirik> #agreed if f21 alpha slips, we will slip 2 weeks to not conflict with flock. (+8,0,0)
17:15:19 <nirik> ok, shall we then just close this and if dgilmore has concerns revisit them next week?
17:15:34 <sgallagh> Ack
17:15:51 <jreznik> ah, another meeting - sorry I missed this topoc
17:15:53 <kylem> seems reasonable to me.
17:16:21 <nirik> #info will keep to the schedule for now, please revisit with additional concerns
17:16:36 <nirik> jreznik: any problems with sticking to schedule and slipping 2 weeks if we need to for alpha?
17:16:49 <pjones> sure.
17:16:53 <jreznik> nirik: it's reasonable
17:16:57 <nirik> great.
17:17:16 <nirik> #topic #1314 FESCo should grant product WGs the right to decide default services
17:17:16 <nirik> .fesco 1314
17:17:16 <nirik> https://fedorahosted.org/fesco/ticket/1314
17:17:18 <zodbot> nirik: #1314 (FESCo should grant product WGs the right to decide default services) – FESCo - https://fedorahosted.org/fesco/ticket/1314
17:17:23 <nirik> sure, +1 from me.
17:17:29 <abadger1999> So... I've been thinking about this.
17:17:44 <abadger1999> I think we might want to reserve the right to specify certain services must be on or must not be on.
17:17:57 <abadger1999> But the deafult should definitely be that WGs decide.
17:18:04 <sgallagh> abadger1999: FESCo's right to overrule is a given
17:18:10 * nirik nods.
17:18:11 <t8m> abadger1999, I think we can override them any time
17:18:19 <mitr> "Yes unless it is a decision I strongly disagree with" (this is going to be popular :) )
17:18:21 <abadger1999> sgallagh: <nod>  I'd just like that to be explicit to set expectations again.
17:18:21 <mitr> Realistically, we can always change our mind or make a special-case exception
17:18:31 <jwb> sigh
17:18:39 <t8m> so +1
17:19:01 <sgallagh> My assertion would be that it would need to be a REALLY strong reason for us to overrule, though
17:19:01 <pjones> I'm +1 to letting them do the job we've delegated to them.
17:19:12 <sgallagh> In general we need to trust the authority of the WGs that we've delegated to
17:19:13 <mattdm> +1 as pjones says
17:19:19 * nirik sees +4 so far
17:19:21 * abadger1999 sees jwb's *sigh* and is willing to discuss the base issue...
17:19:27 <sgallagh> nirik: I'm +1 if that was unclear
17:19:36 <jwb> the continuous need to explicitly state fesco has the ability to override either conveys a significant amount of distrust in the WGs or some kind of inferiority complex among FESCo
17:19:40 <abadger1999> Do we want there to be a basic thing that all Fedora is?
17:19:58 <nirik> as far as record keeping, we should take over the file from systemd package and keep track of it there... (or whatever that is for each product)
17:20:00 <mitr> Rather than a wiki, though, can’t we just agree on how this decision is “packaged” (fedora-release-$product?) and make _that_ the canonical place to see what the WG decisions were?
17:20:09 <sgallagh> abadger1999: That we should (continue to) delegate to the Base WG
17:20:19 <abadger1999> If so, then I think we have to have that sort of expectation that there are certain services that could be set active or inactive for all products.
17:20:22 <nirik> mitr: +1
17:20:22 <t8m> sgallagh, +1
17:20:34 <t8m> mitr, +1 as well
17:20:40 <abadger1999> OTOH, if we don't want that base concept, then there's no reason for fesco to make that demand.
17:21:06 <sgallagh> mitr: That's a different can of worms. dgilmore wants rel-eng to own all the fedora-release-* packages
17:21:09 <sgallagh> With good reason
17:21:20 <abadger1999> sgallagh: sure -- but the last time this came up, it was said that the base wg didn't think that that was part of their job.
17:21:29 <abadger1999> sgallagh: so it's ours until we tell base wg to do it.
17:22:05 <mitr> jwb: or alternatively “this is a question that doesn‘t need answering so much“; where exactly the decision is recorded and who owns the package (^^^) actually ends up mattering more.
17:22:23 <sgallagh> Proposal: FESCo would like the Base WG to be responsible for defining a minimum set of publicly-accessible services that define Fedora. (This can be zero services if that is the decisino)
17:22:27 * nirik is all for telling base they should do this as part of their job... but I think we are driving off the topic of this specifc ticket?
17:22:35 <abadger1999> jwb: I'm wanting to set expectations... I don't want wg's to feel that fesco said "here, you have the power to do this thing" and then later overrulled them arbitrarily.
17:22:42 <jwb> mitr, the latter is true without insisting upon expressing the ability to override
17:22:44 <t8m> sgallagh, why not +1
17:23:00 <jwb> abadger1999, i think you have hammered home that point enough already.
17:23:01 <abadger1999> overuling may happen, but I want the reason for that overruling to be known in advance.
17:23:09 <dgilmore> sorry im here now, my cable modem died and has just been replaced
17:23:09 <mattdm> sgallagh: +1
17:23:15 <jwb> abadger1999, which boils down to BECAUSE FESCo SAID SO
17:23:27 <nirik> so, we have about 3 votes here... making it hard for me to record keep. ;)
17:23:27 <sgallagh> dgilmore: Need a paste of the conversation so far?
17:23:37 <dgilmore> sgallagh: i can read back
17:23:46 <sgallagh> ok
17:23:46 <mitr> sgallagh: +1
17:24:03 <abadger1999> jwb: because fesco said so is the kind of reason that makes it seem arbitrary.
17:24:06 <nirik> ok, lets finish this last proposal first I guess.
17:24:24 * sgallagh apologizes for muddying the waters
17:24:30 <abadger1999> sgallagh: +1 for your last proposal.
17:24:32 <nirik> sgallagh: +1
17:24:34 <kylem> +1 to sgallagh's proposal.
17:24:46 <nirik> ok, thats +7... t8m ?
17:24:51 <nirik> oh, you were already +1
17:24:55 <t8m> yep
17:25:17 <nirik> pjones: ?
17:25:25 <pjones> eh, sure, +1
17:25:46 <nirik> #agreed FESCo would like the Base WG to be responsible for defining a minimum set of publicly-accessible services that define Fedora. (This can be zero services if that is the decisino) (+8,0,0)
17:26:03 <dgilmore> for the record i am +1 to this
17:26:14 <nirik> #undo
17:26:14 <zodbot> Removing item from minutes: AGREED by nirik at 17:25:46 : FESCo would like the Base WG to be responsible for defining a minimum set of publicly-accessible services that define Fedora. (This can be zero services if that is the decisino) (+8,0,0)
17:26:20 <nirik> #agreed FESCo would like the Base WG to be responsible for defining a minimum set of publicly-accessible services that define Fedora. (This can be zero services if that is the decisino) (+9,0,0)
17:26:40 <sgallagh> #undo
17:26:40 <zodbot> Removing item from minutes: AGREED by nirik at 17:26:20 : FESCo would like the Base WG to be responsible for defining a minimum set of publicly-accessible services that define Fedora. (This can be zero services if that is the decisino) (+9,0,0)
17:26:45 <sgallagh> #agreed FESCo would like the Base WG to be responsible for defining a minimum set of publicly-accessible services that define Fedora. (This can be zero services if that is the decision) (+9,0,0)
17:26:52 <sgallagh> (That typo was going to bug me...)
17:26:55 <pjones> I liked decisino
17:27:06 <sgallagh> pjones: Does it change your vote? :)
17:27:09 <pjones> like a 10-sided casino
17:27:41 <abadger1999> pjones: Is it Italian?
17:27:51 <sgallagh> Ok, so back to the rest of the topic...
17:27:55 <nirik> ok, where were we on the question from the ticket? abadger1999: did your concerns get addressed/discussed?
17:28:10 <abadger1999> nirik: yep.
17:28:23 <nirik> ok, so votes on the ticket question?
17:28:24 <nirik> +1
17:28:29 <sgallagh> +1
17:28:31 <t8m> +1
17:28:33 <abadger1999> +1
17:28:38 <mitr> +1
17:29:22 <mitr> And can we actually decide/arrange for the location and ownership of the presets (which seems to be unclear) now?  Or defer for mailng list but keep the ticket open?
17:29:28 <kylem> +1
17:29:44 <mitr> (And https://fedoraproject.org/wiki/Starting_services_by_default will need an update.)
17:29:58 <sgallagh> mitr: Please start a dedicated thread on that
17:30:11 <dgilmore> mitr: i have a few thoughts on implementation, but i think the canonical source should be the packages providing the presets files
17:30:23 <nirik> #agreed FESCo grants WG's the right to decide default services (+6,0,0)
17:30:45 <nirik> yeah, I think the preset files would make sense...wherever they end up.
17:31:13 <sgallagh> I'm going to suggest that this is not the right meeting to discuss implementation
17:31:27 <nirik> yeah, devel list or the like...
17:31:42 <nirik> anything further on this topic? or shall we move on?
17:31:54 <sgallagh> Let's move on
17:32:15 <nirik> #topic #1310 Reconsidering rpcbind's exception allowing it to start by default
17:32:15 <nirik> .fesco 1310
17:32:15 <nirik> https://fedorahosted.org/fesco/ticket/1310
17:32:16 <zodbot> nirik: #1310 (Reconsidering rpcbind's exception allowing it to start by default) – FESCo - https://fedorahosted.org/fesco/ticket/1310
17:32:26 <nirik> there was some testing done this morning... added to last comment
17:32:45 <mitr> And we ended up not having the discussion from last meeting in the ticket.
17:32:47 * kylem tested it last week, but not extensively, with the same conclusions in the last comment.
17:33:10 <mitr> kylem: Did you try rpcbind listening only locally, by any chance?
17:33:13 <sgallagh> If I'm reading it correctly, it sounds like everything works, though there may be a bug with how systemd reports what's running?
17:33:19 <kylem> i had no trouble with rpcbind being chkconfig'd off, when forcing -o nfsvers=3
17:34:13 <kylem> mitr, unsure, not explicitly.
17:34:38 <kylem> i don't recall what iptables rules were on that machine, it's not powered on atm.
17:35:18 <t8m> I'd say let's make it off by default and handle eventual breakage of nfs v3 as regular bug
17:35:21 <kylem> (i also didn't run into steved on thursday, and today is my first day in the office since.)
17:35:35 <nirik> t8m: +1
17:35:37 <t8m> including the intermittent error message
17:35:39 <sgallagh> t8m: +1
17:36:11 <kylem> (i didn't think to test nfsv2, nor v3 with tcp, not sure that it matters at this point though.)
17:36:15 <mitr> t8m: Well, how would you expect that bug to be resolved?  By reenabling it?  (AFAIK portmap is an unavoidable component of NFSv3, it‘s not a “bug” that you need to have it.
17:36:51 <t8m> mitr,  but it works, doesn't it? apart from the delay and intermittent error message
17:37:11 <kylem> does it even matter? the default on most modern linux distros has been nfsv4 for several years.
17:37:33 <nirik> the trick is legacy storage stuff that still does v3...
17:37:43 <nirik> but if we release note what to do that might be enough.
17:38:04 <mitr> kylem: I suppose… and lacking active package maintainer involvement it’s probably wise to default to granting the request.
17:38:55 <nirik> so thats +3 for t8m's proposal I guess...
17:39:09 <t8m> yep, I am +1 to myself
17:39:14 <kylem> i'll +1 it as well.
17:39:29 <pjones> sure, +1
17:39:29 <kylem> worst case, if someone shouts loud, we revisit it. not the end of the world.
17:39:44 <abadger1999> +1 with the same idea as kylem
17:39:46 <kylem> nirik, i wonder who has those. ;-P
17:39:47 <mitr> Yeah, mark me as +1 I guess (though would be slightly happier without the “…and treat as …” prescription)
17:40:33 <nirik> #agreed rpcbind should not start by default. (+7,0,0)
17:40:36 <kylem> i'll try to poke steved about this if he's in today as soon as we're done here.
17:40:50 <nirik> kylem: we actually use v3 in infra, but we could switch to v4... and probibly should.
17:40:59 <t8m> nirik, you should
17:41:04 <t8m> :)
17:41:08 <kylem> nirik, indeed. v4 is... superior.
17:41:13 <nirik> changing this will also need a systemd bug to change the preset?
17:41:18 <sgallagh> Of course it is. It's one higher!
17:41:29 <nirik> well, everytime I have asked netapp folks they have said... meh. not really any different.
17:42:10 <nirik> ok, moving on then...
17:42:19 <nirik> #topic #1311 Disable syscall auditing by default
17:42:20 <nirik> .fesco 1311
17:42:20 <nirik> https://fedorahosted.org/fesco/ticket/1311
17:42:21 <zodbot> nirik: #1311 (Disable syscall auditing by default) – FESCo - https://fedorahosted.org/fesco/ticket/1311
17:42:26 <nirik> there was a new comment just added to this.
17:42:59 <kylem> that's unhelpful. ;-)
17:43:10 <mitr> AFAICT nothing new in that comment anyway
17:43:17 <dgilmore> we were going to disable it by default
17:43:28 * dgilmore needs to follow up and do what he said he would last week
17:43:50 <nirik> oh yeah, we already decided here...
17:44:03 <dgilmore> we can re-evaluate once we have extra data
17:44:16 <nirik> dgilmore: can you update that ticket with agreement and plan?
17:44:48 <dgilmore> nirik: yes sir
17:44:59 <nirik> thanks. ;)
17:45:09 <nirik> #info this was decided last week, will update ticket with info.
17:45:15 <nirik> #topic #1318 shared-mime-info arbitration
17:45:16 <nirik> .fesco 1318
17:45:16 <nirik> https://fedorahosted.org/fesco/ticket/1318
17:45:17 <zodbot> nirik: #1318 (shared-mime-info arbitration) – FESCo - https://fedorahosted.org/fesco/ticket/1318
17:46:08 <nirik> so, sounds like we have a good path for f21...
17:46:14 <nirik> the question is what to do with f20
17:46:28 <mitr> Kind of; there’s little hope of all the existing packages changing for F21
17:46:58 <mitr> So given that, I’d prefer to leave F20 as is (i.e. not to have F20 faster than F21 :) )
17:47:03 * rdieter is here if there are any questions
17:47:16 <t8m> mitr, provenpackager could do that
17:47:34 <t8m> if someone is willing to
17:47:34 <rdieter> mitr: when/if the guildelines get updated, I already offered to implement package scriptlet updates
17:47:46 <mitr> rdieter: ah, great.
17:47:56 <nirik> should be able to possibly script it.
17:47:57 <rdieter> so that part is not in dispute here
17:48:01 <mitr> I still think that this might benefit from a FS expert hopefully surprising everyone with a way to get it both reliable and fast, but that’s out of scope.
17:48:33 <t8m> mitr, +1
17:49:19 <mattdm> I agree that the ship has sailed for f20
17:49:24 <t8m> as for the F20 I agree that we should leave F20 as is
17:49:25 <mitr> The F20 installation from the DVD, or the original repo, will stay slow regardless of what we do, right?  So at best we would improve netinstalls/kickstarts that explicitly enable updates during the initial install?
17:49:32 <dgilmore> mitr: if there is a package to be updated in f20 then they should be adjusted but dont do it just for this
17:49:53 <rdieter> mitr: yes (which is what I do at my site, scratching my itch)
17:50:30 <rdieter> it helps subsequent package updates too, of course
17:50:41 <dgilmore> i think getting to a point where we only call update-mime-database once per transaction is where we should be
17:50:42 <mitr> True
17:51:05 <sgallagh> Proposal: packages are not required to make the update-mime-database change in Fedora 20, but individual package owners are welcome to do so if they wish to keep their packages in sync between F20 and F21
17:51:10 <abadger1999> rdieter: So this fix is going into f20 updates?
17:51:16 <dgilmore> sgallagh: +1
17:51:16 <rdieter> dgilmore: i'd wanted to implement that in fpc a long time ago, but everyone was: meh, for something that only take 0.2 seconds, why bother? :-/
17:51:20 <t8m> sgallagh, +1
17:51:33 <mitr> sgallagh: The FPC proposal depends on a new feature added to shared-mime-info
17:51:42 <mitr> sgallagh: so, +1 to first part, -1 to "but" ATM
17:51:49 <nirik> sgallagh: but not until the f20 one at least ignores the -n right?
17:51:52 <dgilmore> rdieter: but when it effects install time and update tinme as drastically as it does now we should
17:52:09 <rdieter> dgilmore: yeah, definitely.  no disagreement there
17:52:18 <sgallagh> Perhaps I misread; I thought the fix was already (in progress of) being backported
17:52:35 <rdieter> sgallagh: it is in progress, yes
17:53:03 <rdieter> sgallagh: well, the backported fix is only that the new -n option will be accepted (and ignored)
17:53:08 <nirik> yeah, so the only way to partially 'fix' f20, is a package that just drops the sync
17:53:10 <rdieter> the code is too different
17:53:12 <sgallagh> ok
17:53:28 <abadger1999> Okay -- so if it's going to f20 updates, sgallagh's proposal makes sense and Packaging Guidelines should  list F20 and above (rather than F21 and above)
17:53:31 <rdieter> sgallagh: the only question for fesco here now, is: should it use fsync by default or not
17:53:56 <rdieter> abadger1999: I have the fix for f19 too, fwiw
17:53:59 * nirik suspects it may be a gotcha for f19
17:53:59 <sgallagh> rdieter: F20 has been out long enough that I'd rather not risk destabilizing it, personally
17:54:22 <rdieter> sgallagh: frankly, theres ~0% chance of that
17:54:26 <rdieter> imho
17:54:43 <rdieter> but I'm biased
17:55:16 * nirik thinks the maintainer is being somewhat unreasonable here, but overriding them is not something to do lightly.
17:55:25 <sgallagh> I'm not familiar enough with the detail here to make an informed decision, so defaulting to "how it's been working for the last seven months" is good enough for me.
17:55:45 <abadger1999> So this is just creating a cache?
17:55:55 <nirik> yes
17:56:20 * abadger1999 agrees with nirik's sentiment...
17:56:36 <mitr> abadger1999: but a cache that is required to be present, and if corrupted the applications won’t magically ignore it
17:56:38 <rdieter> abadger1999: it's generating the stuff in /usr/share/mime/ from the /usr/share/mime/packages/ xml input
17:56:38 <abadger1999> not sure if that makes me +1 or -1 to overruling, though.
17:56:51 <mitr> nirik: Well it _does_ bite both ways; if they are (IIRC on past experience) convinced that fdatasync() for installed files is necessary, I can’t see why it shouldn’t be required for _all_ installed files, including all RPM payload.  Are we consistent in our choices?
17:57:13 <nirik> of course we aren't. ;)
17:57:48 <mitr> OK, to be more limited: are we doing installs and updates safely?  (“of course we aren’t", yeah, well)
17:57:49 <rdieter> mitr: rpm payload can be verified at least
17:58:00 <mitr> rdieter: ah, good point.
17:58:22 <rdieter> but I'd argue output that can be regenerated on the fly in ~0.2 seconds, isn't worth caring much about
17:58:43 <nirik> but users with corrupted ones may not know how to regen the cache or whats causing weird icons
17:58:56 <mitr> rdieter: I have asked in the ticket: what happens if it is corrupted, and how would the user know to regenerate it?
17:59:07 <rdieter> they don't
17:59:27 <abadger1999> So one way of looking at this is... there's a performance regression from f19 to f20.  We should restore performance by default in f20 and use f21 to fix the bug that prompted the regression properly.
17:59:30 <mitr> (suddenly a “safe boot” that blows all caches and magically fixes some problems starts to look kinda smart)
17:59:51 <rdieter> hadess claimed there were real world crashes due to corruption, but I didnt get any answer asking for more details
17:59:53 <abadger1999> The other way is there's bad performance in f20.  We will just wait for f21 to optimize that.
18:00:18 <mitr> abadger1999: More precisely, our hands for F20 are kinda tied.  We can improve (yum update) and fairly custom installs, only.
18:00:49 <nirik> with the -n backport also is the env variable to override the sync?
18:00:57 <nirik> or that env is only f21+?
18:00:59 <rdieter> nirik: yes
18:01:09 <rdieter> the env variable is available
18:01:11 <abadger1999> mitr: isn't install with update repositories still standard in anaconda?
18:01:46 <rdieter> again, the only issue at hand, is whether fsync is enabled, *by default* or not
18:01:49 <abadger1999> mitr: if so, then it's not just fairly custom installs we could fix the regression for.
18:02:22 <nirik> I guess I am slightly toward 'leave f20 alone'
18:02:44 <nirik> do we want to vote here? or more questions/discussion?
18:03:17 <mitr> proposal: FESCo doesn’t require the fdatasync() behavior in F20 shared-mimo info to be modified
18:03:22 <mitr> (+1 for the record)
18:03:41 <kylem> +1
18:03:42 <nirik> +0.5... ok, +1
18:03:42 <sgallagh> mitr: +1
18:03:47 <pjones> +1
18:04:03 <t8m> +1 from me as well, although there is performance regression i am ok fixing it in F21 only
18:04:13 <abadger1999> rdieter: are you asking for changing the default in the code or that we start providing something that sets that env var?
18:04:34 <dgilmore> me is 0
18:04:36 <rdieter> abadger1999: either I guess, but what I had in mind was in code
18:04:43 <abadger1999> k
18:04:47 <rdieter> the result would be the same
18:05:29 <abadger1999> On mitr's proposal, 0 if it's in code; -1 if it's set via the env var
18:05:44 <nirik> #agreed FESCo doesn’t require the fdatasync() behavior in F20 shared-mimo info to be modified (+6,+2,0)
18:06:10 <nirik> anything else on this? sorry rdieter...
18:06:24 <rdieter> no problem.  that's all, I can go submit something to bodhi now.
18:06:42 <nirik> thanks a lot for tracking this down and driving it forward.
18:06:46 <rdieter> I'll just keep a fork in my local site repo, cause I don't like waiting
18:06:47 <nirik> #topic #1321 Can packages not approved for Fedora be placed in non-official branches of the Fedora pkgs repo?
18:06:47 <nirik> .fesco 1321
18:06:47 <nirik> https://fedorahosted.org/fesco/ticket/1321
18:06:48 <zodbot> nirik: #1321 (Can packages not approved for Fedora be placed in non-official branches of the Fedora pkgs repo?) – FESCo - https://fedorahosted.org/fesco/ticket/1321
18:08:04 <t8m> I think the topic is slightly misleading
18:08:30 <abadger1999> t8m: I don't think so -- but I do think that multiple things are being conflated in the ticket.
18:08:44 <mattdm> So to paraphrase nirik in the last comment there: dist-git isn't a very good fit for this, but we also don't have anything else that is.....
18:08:57 <t8m> mattdm, +1
18:09:01 <nirik> I think as it is now, pkgs dist git is a bad place for things not intended to be built as official fedora packages.
18:09:16 <nirik> well, I made some suggestions, but no one answered. ;)
18:09:22 <abadger1999> mattdm: Sure -- but then should I be able to checkin my python-newmodule to a different package that I own until it is reviewed?
18:09:44 <dgilmore> right now we can not remove any content from dist-git at all
18:09:58 <mitr> abadger1999: That's really not a fair characterization of what is happening
18:10:02 <dgilmore> we need some work to make sure builds are done from appropriate branches
18:10:08 <mattdm> dgilmore yeah _that_ seems like a big reason not to do this.
18:10:17 <dgilmore> so people doing work in side branches ahve to leave it there
18:10:37 <nirik> or can I check in the mingw version of my package that I have not submitted for review yet?
18:10:38 <t8m> dgilmore, that seems like bug in koji though :) or a seriously needed feature
18:10:49 <dgilmore> we want to get to a point where we can allow people to delete things used to experiment
18:10:58 <dgilmore> t8m: its not a bug in koji
18:10:59 <mitr> OTOH long-term something centralized (very much like existing pkgs) is clearly what we need for copr and things; having it scattered over fedorapeople and even fedorahosted wouldn”t do.
18:11:06 <nirik> for the record I would love to enhance dist git.
18:11:12 <abadger1999> nirik: I agree that we already provide fedorapeople git which is the clposest thing w ecurrently provide that fills this niche
18:11:15 <dgilmore> t8m: its a bug in how dist-git was developed
18:11:20 <dgilmore> and its never been fixed
18:11:43 <mattdm> #help we sure could use a lot of enhancements to our tools to support these ues cases
18:11:46 <abadger1999> mitr: As I see it is.  You can present an alternative and I can see where we're disagreeing though.
18:11:54 <dgilmore> mattdm: indeed
18:12:29 <dgilmore> I have concerns over poluting lookaside cache with this also
18:12:37 <dgilmore> but we could do tooling to work around that
18:12:55 <mitr> abadger1999: In all cases we have been discussing, the content in the branches is _clearly related_ (at the very least derived from, if not regularly branched from) to the primary branches
18:13:12 <mitr> It’s not like anyone is committing chrome.spe in there
18:14:06 <nirik> I guess the question is how much 'related' should something be.
18:14:29 <abadger1999> mitr: Ah -- but that's still a very grey definition.  mingw, scls, compat packages all fall in there.
18:14:50 <nirik> new/nightly of exact same package? mingw version? python3 version? scl version? suse package?/
18:14:55 <mitr> abadger1999: As I said in the ticket, we allow arbitrary half-finished personal branches, so why not this?
18:15:03 <abadger1999> Shoot, you could even say that python-foo and python-bar only differ in the name, summary, and description field so why can't I derive one from the other?
18:15:03 <t8m> mitr, +1
18:15:19 <t8m> abadger1999, that is absurd
18:15:23 <abadger1999> mitr: Of the same package or of different packages?
18:15:32 <mattdm> abadger1999 can you articulate the harm other than organizational cleanliness?
18:15:36 <abadger1999> t8m: the second example?  Or the first one?
18:15:44 <mitr> (Ultimately whatever mechanism we end up using, the git repo storage is paid for and maintaned by Fedora, so there’s nothing much)
18:15:51 <t8m> abadger1999, the last one
18:16:14 <dgilmore> mitr: there is also lookaside storage
18:16:28 <dgilmore> mitr: we never delete from lookasie
18:16:30 <nirik> mattdm: 1) they would stick around forever. People visiting cgit for the package could get confused whats used 2) noise to package co-maintainers to something they dont care abou
18:16:32 <dgilmore> lookaside
18:16:35 <t8m> I think the bugs in dist git (not able to remove private branches, allowing building oficial fedora packages from private branches) should be fixed
18:16:42 <abadger1999> t8m: Sure -- I probably should have put a smiley by that.... but the point of hte last example is that we're not talking about differences here of how much is changed between packages but relation to each other.
18:16:56 <dgilmore> if someone is pulling in nightly snapshots of a big upstream project that will quickly use up disk
18:17:08 <mitr> dgilmore: Yes, and we would end up wanting to store these files for COPR just as well, and people hosting RPMs in fedorapeople would want the tarballs hosted just as well,
18:17:30 <abadger1999> mattdm: Also -- permissions.  If the packager in copr doesn't have permissions to the pakcage, they have to figure something else out anyway.
18:18:19 <nirik> t8m: patches welcome! :)
18:18:21 * nirik runs
18:19:05 <mitr> I suppose:
18:19:07 <mitr> proposal: FESCo finds it long-term desirable to have packaging of various initiatives within the Fedora project, including at least the main distribution, Playground and possibly other SCLs within some kind of common infrastucture
18:19:08 <nirik> one of the uses for these seems to be nightly builds... thats a lot of scm commits noise also
18:19:10 <mitr> … as a statement of intent; if we agreed about that, we could continue discussing the more difficult part of where to get the contributions necessary for getting there.
18:19:15 <abadger1999> mattdm: I made a list of things that we need to change in our current tooling to properly support this in one of my early comments.  You can also read that as a list of reasons why it's not good to do this as it is now.
18:19:51 <t8m> not sure whether these patches would be more hard to write than code checking whether private branches contain really only small and relevant things to the respective package packaging development :)
18:19:59 <nirik> mitr: I could agree to that, but the devil is in the details of course. ;)
18:20:25 <abadger1999> mitr: For some definition of "common" in that statement.  I do not think that re-using the same git repos for all of those things is desirable.  But having them all hosted on fedora infrastructure boxes definitely is.
18:20:29 <mitr> nirik: yeah, the above doesn't actually rule out having pkgs and pkgs-copr separate installations of the same software
18:20:48 <mitr> but it does rule out some of the proposed alternatives like fedorapeople
18:20:59 <t8m> mitr, +1
18:21:06 <abadger1999> mitr: uhh... the way I read it, fedorapeople is okay.
18:21:13 <mitr> abadger1999: could you dig up an exact link for the “list of things that need to change in our current tooling"?
18:21:15 <nirik> mitr: long term sure... now, no?
18:21:45 <abadger1999> mitr: last paragraph of the initial ticket description.
18:22:05 <mitr> abadger1999: ah, thanks.
18:22:36 <nirik> perhaps we could discuss now, short term and long term?
18:22:45 <abadger1999> mitr: fedorapeople is hosted by fedora infra.... why would it not be allowable as "common infra"  (Reason I'm asking is the restrictions you see ruling that out might also mean I don't agree with the proposal).
18:22:59 <dgilmore> mitr: an option could be a second set of repos and seperate lookaside cache
18:23:09 <dgilmore> it would tae some work to sort it out
18:23:27 <dgilmore> and would need a new fedpkg like tool
18:23:48 <mitr> abadger1999: impossibility to write tools that work with “all” packages
18:23:49 <nirik> how much demand is there for this?
18:24:18 <nirik> do we know?
18:25:27 <abadger1999> long term, I'd like to see experimental packaging (different packaging, git repos specially for copr, git repos for packages under review) have a git repository. I'd want these to be hosted in a separate git-repo (could still be pkgs.fp.o but the git-repo is different) because they count as different packages as the ones in mainstream fedora going off in divergent directions.
18:26:06 <abadger1999> nirik: Recently, there's been a flurry of these requests from a small team of people.
18:26:35 <nirik> If it becomes feasable, I'd love to have something like gitlab... where any maintainer(or anyone) could make repos for whatever packaging they are playing with, etc...
18:26:43 <mitr> dgilmore: separate lookaside would be somewhat inconvenient (but not a dealbreaker) for merging across the systems; would it actually help you with storage at all?  It kindof seems to me that whatever GC that would be done per-repo in the separate system can also be done per-branch in the main system.
18:27:00 <nirik> mitr: we do not GC lookaside.
18:27:05 <abadger1999> compared to the entire packageset, probably not large, though.
18:27:14 <abadger1999> kind of a squaky wheel?
18:27:14 <mitr> nirik: i.e. there is no difference at this moment and no reason to split?
18:27:19 <abadger1999> *squeeky
18:27:53 <nirik> mitr: I suppose, but if someone is going to make nightly python3 builds until the end of time... it might be good to know that we have to play for much larger expansion of storage over time.
18:28:07 <abadger1999> *pay
18:28:12 <nirik> and all those sources are not things in official fedora packages, so it seems sad to use our disk for them.
18:28:19 <dgilmore> mitr: separate lookaside means we could easily work out a way to clean old things out
18:28:20 <nirik> actually plan.
18:28:46 <mitr> dgilmore: thanks
18:28:47 <dgilmore> mitr: but it would mean uploading things again when deciding its ready for fedora
18:29:32 <nirik> proposal: do not use pkgs dist-git for changes not directly going into official packages for now. Work with infrastructure to plan a git for these uses, use fedorapeople or external services for now.
18:29:49 <dgilmore> nirik: +1
18:29:58 <kylem> nirik, +1
18:30:00 <abadger1999> nirik: +1
18:30:44 <nirik> more votes? ;) or counterproposals?
18:31:10 <mattdm> I guess I'm +1. I wish we did have something better in place
18:31:16 <mattdm> but wishes and horses and all that :)
18:31:43 <pjones> +1
18:31:48 <mitr> -1; I’d rather have work-in-progress and notes and all sharable in there
18:32:03 <t8m> -1
18:32:25 <mitr> nirik: Would
18:32:27 <mitr> proposal: Do not use pkgs dist-git for changes that require new lookaside-cache files for now. Work with ….
18:32:29 <mitr> be acceptable?
18:32:48 <mitr> That should address the primary costs at least
18:33:17 <abadger1999> Not for me.  because there's the question of related packages that would need a separate review and a separate git repo once reviewed.
18:33:22 <nirik> I don't think so... that doesn't address the other issues.
18:33:41 <abadger1999> compat packages, mingw, etc.
18:34:03 <t8m> or rather 0 as I understand that allowing anything (legally OK) in separate branches is a problem
18:34:07 <mitr> abadger1999: git repo is just a storage menchanism.  There is no requirement for everything stored in Fedora infrastructure to go through FPC reviews
18:35:03 <nirik> cool. I can upload my backups to pkgs? ;)
18:35:09 <pingou> \ó/
18:35:34 <kylem> nirik, encrypt them and upload to the lookaside. what could possibly go wrong
18:35:42 <abadger1999> mitr: It's not "just a storage mechanism" by convention.  As t8m wrote above about some examples being absurd shows
18:36:04 <mitr> *sigh* So let me simplify, I just find the insistence on FPC reviews absurd.
18:36:18 <t8m> mitr, +1
18:36:33 <nirik> reviews of what?
18:36:52 * nirik notes we have enough votes to pass, I guess we could move on.... but I like to know the concern
18:37:06 <mitr> If the same people want to maintaint substantially similar packaging of the same upstreams within the same public git repo, I think that’s a convenient and natural thing to do, might benefit other people, and Fedora project just looses if this ends up hosted at github or whatever.
18:37:18 <t8m> mitr, +1
18:37:38 <mitr> nirik: Sorry, let’s move on then.  I don’t want to be a pest about it.
18:37:42 <abadger1999> substantially similar is likely the sticking point.
18:37:44 <dgilmore> mitr: part of why things are as they are is to make things easy to find
18:38:01 <mitr> abadger1999: Oh Come On.
18:38:28 * abadger1999 notes that the nightly aspect doesn't bother him... it's the changes to the spec file that aren't ever destined for the mainstream package.
18:38:44 * pingou wonders why would one want to store nightly in a git
18:38:48 <dgilmore> mitr: if people go putting things in different branches for convenience in developing or maintaining, we may end up having trouble to go find the source of things
18:38:51 <abadger1999> The nightly aspect runs into the lookaside problems... but that's a separate concern than the one that prompted me to open the ticket.
18:39:23 <nirik> #agreed do not use pkgs dist-git for changes not directly going into official packages for now. Work with infrastructure to plan a git for these uses, use fedorapeople or external services for now. (+6,0,-2)
18:39:31 <nirik> #topic 1320 Proposal: trivial patch policy
18:39:31 <nirik> .fesco 1320
18:39:31 <nirik> https://fedorahosted.org/fesco/ticket/1320
18:39:32 <mitr> dgilmore: From the outside it seems that the main branches have specific non-optional names; if the implementation is actually more flexible, that’s a concern
18:39:33 <zodbot> nirik: #1320 (Proposal: trivial patch policy) – FESCo - https://fedorahosted.org/fesco/ticket/1320
18:39:52 <dgilmore> mitr: right now there is zero enforcement
18:39:54 <nirik> mitr: right now, you can build from any git hash
18:40:39 <dgilmore> mitr: there are things that need fixing in the design and implementation of dist-git
18:40:40 * smani here to answer questions
18:41:48 <t8m> we could simply say that and not enforce in the dist-git code as we simply say that statement above and not enforce it in git anyway
18:41:57 <t8m> but never mind
18:42:13 <mitr> Or we could temporarily prohibit the use of other branches unless someone wants them badly enough to write the enforcement patch?
18:42:25 <mitr> (re: #1320, all I wanted to say is in comment:1)
18:42:35 <nirik> mitr: thats what we did isn't it?
18:42:44 <dgilmore> mitr: anyone with access can create a push a branch, we just cant delete it
18:42:57 <mattdm> I'm +1 to #1320. It seems like a nice step forward.
18:43:07 <mitr> nirik: I didn’t read it like that, good point.
18:43:26 <dgilmore> re, 1320 im +1 but i agree it could hide issues when dealling with ftbfs packages
18:43:40 <nirik> I'm +1 to give it a try... I'm hoping having a tracker bug would help get more provenpackagers involved in fixing things.
18:43:52 <mitr> +1 for the record
18:43:58 <t8m> +1
18:44:31 <abadger1999> +1 with the same reservations as dgilmore and scop.
18:44:45 <smani> so just to jump in: The hardest part is probably to define how far "simple" patches can go, I tried to list a few cases, I'd be interested in hearing if people have other opinions
18:44:47 <nirik> thats +6... any other votes? do we want to adjust anything for the ftbfs concern?
18:45:35 <nirik> smani: I would hope provenpackagers would use good judgement in refusing things that are not approprate...
18:45:53 <dgilmore> nirik: im not sure there is a great way to deal with the ftbfs concern, which is more a how do we find inactive maintainers concern
18:46:27 <nirik> yep. our inactive policy needs a complete rewrite. We have a lot more info than we used to...
18:46:53 <dgilmore> i know we have had to fix some ftbfs on primary to unblock other things on secondary arches
18:47:10 <mattdm> we should be able to count the number of bugs for a certain package which block the tracker
18:47:29 <mattdm> that number gives us _more_ information on inactive maintainers than just ftbfs
18:47:42 <nirik> theres a lot of info we could put together on maintainers and on specific packages.
18:48:04 <dgilmore> mattdm: we should be able to use the data we have to see if maintainers have not contributed in years, and identify packages that have only been updated for mass rebuilds
18:48:04 <nirik> maintainers: last commit, last fas login, last mailing list post, last build, last fedmsg of any kind related to them, etc.
18:48:29 <dgilmore> which in itself is not necessariy a problem but with linger bug reprts etc is
18:48:30 <nirik> packages: last commit by packager X, last commit at all, last build, last qa results, number of updates, etc etc
18:48:46 <nirik> anyhow... thats drifting into another topic.
18:48:52 <dgilmore> nirik: right
18:48:59 <mattdm> if a certain package has had N "spp" bugs against it in a year, flag it...
18:49:04 <t8m> didn't we have a separate ticket for this?
18:49:07 <nirik> #agreed policy is approved (+6,0,0)
18:49:11 <nirik> t8m: yeah
18:49:22 <dgilmore> so i think ftbfs fixes is kinda a concern in masking things and maybe keeping things in that should be removed
18:49:31 <nirik> thanks for working on this smani. Can you setup the tracker bug and add the policy to the wiki, etc?
18:49:39 <dgilmore> but i wouldnt make it a blocker on getting people to help fix simple issues
18:50:11 <smani> nirik: yes will do so
18:50:30 <nirik> as an unrelated note: the 'distribution' component has a ton of open bugs that can be closed/reassigned/cleaned up. :) Do we still need a ia64 tracker?
18:50:48 <nirik> smani: cool. let me know if I can assist with any of it.
18:50:55 <nirik> #topic Next week's chair
18:51:00 <nirik> who wants the hot potatoe?
18:51:15 <smani> nirik: ok!
18:51:30 * sgallagh might not make it next wek.
18:51:33 <sgallagh> *week
18:51:35 <mattdm> I think it's probably about my turn :)
18:51:44 <nirik> cool. Thanks
18:51:50 <nirik> #info mattdm to chair next week
18:51:53 <nirik> #topic Open Floor
18:52:01 <nirik> anyone have anything for open floor?
18:52:33 <dgilmore> nirik: quick back track to the first topic
18:52:45 <nirik> I had one thought: could the folks vacating fesco seats in this special election perhaps do a quick blog post on why? I saw some confusion in social media as to why so many fesco memebers were leaving...
18:52:53 <dgilmore> im likely going to spend the week of July 28 in brno
18:52:55 <nirik> dgilmore: oh yeah, whats your plans?
18:54:01 <nirik> ok, then you are ok with sticking to schedule?
18:54:16 <dgilmore> i still need to make them  but right now im planning to be in Brno July-28 through August 5
18:54:24 <dgilmore> yep i am
18:54:53 <nirik> cool.
18:56:16 <nirik> ok, if nothing else will close in a minute or less.
18:56:34 <kylem> thanks very much nirik.
18:56:42 <kylem> fwiw, i'll be on PTO for the next two meetings. :/
18:56:57 <nirik> ok, hopefully going somewhere fun. ;)
18:57:00 <kylem> shortest fesco tenure ever. ;-)
18:57:18 <nirik> :)
18:57:23 <nirik> ok, thanks for coming everyone.
18:57:25 <nirik> #endmeeting