#fedora-meeting: FESCO (2014-07-02)
Meeting started by nirik at 17:00:27 UTC. The full logs are available at
* init process (nirik, 17:00:27)
* #1178 Fedora 21 scheduling strategy (nirik, 17:03:39)
* LINK: https://fedorahosted.org/fesco/ticket/1178
* AGREED: if f21 alpha slips, we will slip 2 weeks to not conflict
with flock. (+8,0,0) (nirik, 17:15:02)
* will keep to the schedule for now, please revisit with additional
concerns (nirik, 17:16:21)
* #1314 FESCo should grant product WGs the right to decide default
services (nirik, 17:17:16)
* LINK: https://fedorahosted.org/fesco/ticket/1314
* 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)
* AGREED: FESCo grants WG's the right to decide default services
(+6,0,0) (nirik, 17:30:23)
* #1310 Reconsidering rpcbind's exception allowing it to start by
default (nirik, 17:32:15)
* LINK: https://fedorahosted.org/fesco/ticket/1310
* AGREED: rpcbind should not start by default. (+7,0,0) (nirik,
* #1311 Disable syscall auditing by default (nirik, 17:42:19)
* LINK: https://fedorahosted.org/fesco/ticket/1311
* this was decided last week, will update ticket with info. (nirik,
* #1318 shared-mime-info arbitration (nirik, 17:45:15)
* LINK: https://fedorahosted.org/fesco/ticket/1318
* AGREED: FESCo doesn’t require the fdatasync() behavior in F20
shared-mimo info to be modified (+6,+2,0) (nirik, 18:05:44)
* #1321 Can packages not approved for Fedora be placed in non-official
branches of the Fedora pkgs repo? (nirik, 18:06:47)
* LINK: https://fedorahosted.org/fesco/ticket/1321
* HELP: we sure could use a lot of enhancements to our tools to
support these ues cases (mattdm, 18:11:43)
* 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) (nirik, 18:39:23)
* 1320 Proposal: trivial patch policy (nirik, 18:39:31)
* LINK: https://fedorahosted.org/fesco/ticket/1320
* AGREED: policy is approved (+6,0,0) (nirik, 18:49:07)
* Next week's chair (nirik, 18:50:55)
* mattdm to chair next week (nirik, 18:51:50)
* Open Floor (nirik, 18:51:53)
Meeting ended at 18:57:25 UTC.
Action Items, by person
People Present (lines said)
* nirik (162)
* mitr (66)
* abadger1999 (63)
* dgilmore (50)
* sgallagh (44)
* t8m (38)
* rdieter (27)
* kylem (24)
* mattdm (23)
* zodbot (16)
* pjones (14)
* jwb (5)
* smani (4)
* pingou (2)
* jreznik (2)
* blackbird (1)
* mmaslano (0)
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'
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(a)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 -
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
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
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
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
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
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
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
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
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
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
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
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
17:30:45 <nirik> yeah, I think the preset files would make sense...wherever they end
17:31:13 <sgallagh> I'm going to suggest that this is not the right meeting to
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
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
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 -
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 -
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
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
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
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
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
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 -
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
18:10:02 <dgilmore> we need some work to make sure builds are done from appropriate
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
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
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
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
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
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
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
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
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”
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,
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
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
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
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
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
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
18:39:33 <zodbot> nirik: #1320 (Proposal: trivial patch policy) – FESCo -
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
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