17:00:27 #startmeeting FESCO (2014-07-02) 17:00:27 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:27 #meetingname fesco 17:00:27 #chair abadger1999 dgilmore jwb kylem mattdm mitr mmaslano nirik pjones sgallagh t8m 17:00:27 #topic init process 17:00:27 The meeting name has been set to 'fesco' 17:00:27 Current chairs: abadger1999 dgilmore jwb kylem mattdm mitr mmaslano nirik pjones sgallagh t8m 17:00:32 hello. 17:00:41 .hellomynameis sgallagh 17:00:42 sgallagh: sgallagh 'Stephen Gallagher' 17:01:08 hello 17:01:17 szia 17:01:21 .hellowmynameis mattdm 17:01:42 .hellowmynameis pjones 17:01:44 Hello 17:01:56 (no w in hello :) 17:02:03 .hellomynameis pjones 17:02:04 pjones: pjones 'Peter Jones' 17:02:17 yeah, totally works better if we don't copy-pasta eachother's misspelled "hello". 17:02:29 morning. 17:02:53 yay! 17:02:54 dgilmore / abadger1999 ? 17:03:32 ok, we have quorum I guess so we can go ahead and get started. 17:03:39 #topic #1178 Fedora 21 scheduling strategy 17:03:40 .fesco 1178 17:03:40 https://fedorahosted.org/fesco/ticket/1178 17:03:42 nirik: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178 17:03:50 hola 17:04:01 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 mattdm: ouch. ;( 17:04:46 mattdm: Here, just sign this. No you don't need to read it... 17:04:49 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 nirik I was more offended than actuallh hurt. I was *just sitting there!* 17:05:10 wasps are jerks. :) 17:05:19 If it helps, you probably killed the wasp. 17:05:55 nirik: Assuming we hit our deliverable, I'd *love* to be able to manufacture some Alpha (RC?) liveusb's for Flock 17:06:11 pjones: it flew off and and was buzzing around after. *sigh* 17:06:15 annnyway :) 17:06:29 But if we do slip, we'll be in blocker-resolution mode DURING the conference 17:06:40 Which is certainly unfortunate 17:06:43 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 but it might still be ok. 17:07:12 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 dgilmore: When are you travelling to flock? 17:08:00 * nirik isn't sure what dgilmore's travel plans are. 17:08:36 we are pretty good at boring releases in infrastructure anymore (he says, totally jinxing it)... 17:09:13 nirik: is that a promise for a non-boring release? ;-) 17:09:19 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 abadger1999: I think we can reasonably assume (given Fedora.next) that this will *not* be a boring release :) 17:10:24 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 shall we just defer this to next week and ask dgilmore ? 17:11:32 nirik: Different question: does anyone have a current expectation that this date is a bad idea 17:11:50 If not, let's stick with that date and slip it if rel-eng concerns come up 17:12:01 (I'm opposed to trying to do it sooner) 17:12:21 see tflink's comment. 17:12:31 basically the bad idea would be if we slip a week... 17:12:42 then everyone is busy trying to fix blockers and being at flock 17:12:59 nirik: yeah, I think that if we do that, we basically have to slip by two weeks. 17:13:13 Proposal: If an Alpha slip occurs, we make it two weeks to not conflict with Flock 17:13:26 Let's just say that up-front 17:13:39 sure, +1 17:13:48 +1 17:13:49 +1 17:13:52 +1 17:13:53 sgallagh: yeah, to set expectations. +1 to that 17:13:53 * sgallagh is +1 for the record 17:14:07 sure, +1 17:14:28 #agreed if f21 alpha slips, we will slip 2 weeks to not conflict with flock. (+7,0,0) 17:14:52 +1 for the record 17:14:58 #undo 17:14:58 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 #agreed if f21 alpha slips, we will slip 2 weeks to not conflict with flock. (+8,0,0) 17:15:19 ok, shall we then just close this and if dgilmore has concerns revisit them next week? 17:15:34 Ack 17:15:51 ah, another meeting - sorry I missed this topoc 17:15:53 seems reasonable to me. 17:16:21 #info will keep to the schedule for now, please revisit with additional concerns 17:16:36 jreznik: any problems with sticking to schedule and slipping 2 weeks if we need to for alpha? 17:16:49 sure. 17:16:53 nirik: it's reasonable 17:16:57 great. 17:17:16 #topic #1314 FESCo should grant product WGs the right to decide default services 17:17:16 .fesco 1314 17:17:16 https://fedorahosted.org/fesco/ticket/1314 17:17:18 nirik: #1314 (FESCo should grant product WGs the right to decide default services) – FESCo - https://fedorahosted.org/fesco/ticket/1314 17:17:23 sure, +1 from me. 17:17:29 So... I've been thinking about this. 17:17:44 I think we might want to reserve the right to specify certain services must be on or must not be on. 17:17:57 But the deafult should definitely be that WGs decide. 17:18:04 abadger1999: FESCo's right to overrule is a given 17:18:10 * nirik nods. 17:18:11 abadger1999, I think we can override them any time 17:18:19 "Yes unless it is a decision I strongly disagree with" (this is going to be popular :) ) 17:18:21 sgallagh: I'd just like that to be explicit to set expectations again. 17:18:21 Realistically, we can always change our mind or make a special-case exception 17:18:31 sigh 17:18:39 so +1 17:19:01 My assertion would be that it would need to be a REALLY strong reason for us to overrule, though 17:19:01 I'm +1 to letting them do the job we've delegated to them. 17:19:12 In general we need to trust the authority of the WGs that we've delegated to 17:19:13 +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 nirik: I'm +1 if that was unclear 17:19:36 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 Do we want there to be a basic thing that all Fedora is? 17:19:58 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 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 abadger1999: That we should (continue to) delegate to the Base WG 17:20:19 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 mitr: +1 17:20:22 sgallagh, +1 17:20:34 mitr, +1 as well 17:20:40 OTOH, if we don't want that base concept, then there's no reason for fesco to make that demand. 17:21:06 mitr: That's a different can of worms. dgilmore wants rel-eng to own all the fedora-release-* packages 17:21:09 With good reason 17:21:20 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 sgallagh: so it's ours until we tell base wg to do it. 17:22:05 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 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 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 mitr, the latter is true without insisting upon expressing the ability to override 17:22:44 sgallagh, why not +1 17:23:00 abadger1999, i think you have hammered home that point enough already. 17:23:01 overuling may happen, but I want the reason for that overruling to be known in advance. 17:23:09 sorry im here now, my cable modem died and has just been replaced 17:23:09 sgallagh: +1 17:23:15 abadger1999, which boils down to BECAUSE FESCo SAID SO 17:23:27 so, we have about 3 votes here... making it hard for me to record keep. ;) 17:23:27 dgilmore: Need a paste of the conversation so far? 17:23:37 sgallagh: i can read back 17:23:46 ok 17:23:46 sgallagh: +1 17:24:03 jwb: because fesco said so is the kind of reason that makes it seem arbitrary. 17:24:06 ok, lets finish this last proposal first I guess. 17:24:24 * sgallagh apologizes for muddying the waters 17:24:30 sgallagh: +1 for your last proposal. 17:24:32 sgallagh: +1 17:24:34 +1 to sgallagh's proposal. 17:24:46 ok, thats +7... t8m ? 17:24:51 oh, you were already +1 17:24:55 yep 17:25:17 pjones: ? 17:25:25 eh, sure, +1 17:25:46 #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 for the record i am +1 to this 17:26:14 #undo 17:26:14 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 #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 #undo 17:26:40 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 #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 (That typo was going to bug me...) 17:26:55 I liked decisino 17:27:06 pjones: Does it change your vote? :) 17:27:09 like a 10-sided casino 17:27:41 pjones: Is it Italian? 17:27:51 Ok, so back to the rest of the topic... 17:27:55 ok, where were we on the question from the ticket? abadger1999: did your concerns get addressed/discussed? 17:28:10 nirik: yep. 17:28:23 ok, so votes on the ticket question? 17:28:24 +1 17:28:29 +1 17:28:31 +1 17:28:33 +1 17:28:38 +1 17:29:22 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 +1 17:29:44 (And https://fedoraproject.org/wiki/Starting_services_by_default will need an update.) 17:29:58 mitr: Please start a dedicated thread on that 17:30:11 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 #agreed FESCo grants WG's the right to decide default services (+6,0,0) 17:30:45 yeah, I think the preset files would make sense...wherever they end up. 17:31:13 I'm going to suggest that this is not the right meeting to discuss implementation 17:31:27 yeah, devel list or the like... 17:31:42 anything further on this topic? or shall we move on? 17:31:54 Let's move on 17:32:15 #topic #1310 Reconsidering rpcbind's exception allowing it to start by default 17:32:15 .fesco 1310 17:32:15 https://fedorahosted.org/fesco/ticket/1310 17:32:16 nirik: #1310 (Reconsidering rpcbind's exception allowing it to start by default) – FESCo - https://fedorahosted.org/fesco/ticket/1310 17:32:26 there was some testing done this morning... added to last comment 17:32:45 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 kylem: Did you try rpcbind listening only locally, by any chance? 17:33:13 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 i had no trouble with rpcbind being chkconfig'd off, when forcing -o nfsvers=3 17:34:13 mitr, unsure, not explicitly. 17:34:38 i don't recall what iptables rules were on that machine, it's not powered on atm. 17:35:18 I'd say let's make it off by default and handle eventual breakage of nfs v3 as regular bug 17:35:21 (i also didn't run into steved on thursday, and today is my first day in the office since.) 17:35:35 t8m: +1 17:35:37 including the intermittent error message 17:35:39 t8m: +1 17:36:11 (i didn't think to test nfsv2, nor v3 with tcp, not sure that it matters at this point though.) 17:36:15 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 mitr, but it works, doesn't it? apart from the delay and intermittent error message 17:37:11 does it even matter? the default on most modern linux distros has been nfsv4 for several years. 17:37:33 the trick is legacy storage stuff that still does v3... 17:37:43 but if we release note what to do that might be enough. 17:38:04 kylem: I suppose… and lacking active package maintainer involvement it’s probably wise to default to granting the request. 17:38:55 so thats +3 for t8m's proposal I guess... 17:39:09 yep, I am +1 to myself 17:39:14 i'll +1 it as well. 17:39:29 sure, +1 17:39:29 worst case, if someone shouts loud, we revisit it. not the end of the world. 17:39:44 +1 with the same idea as kylem 17:39:46 nirik, i wonder who has those. ;-P 17:39:47 Yeah, mark me as +1 I guess (though would be slightly happier without the “…and treat as …” prescription) 17:40:33 #agreed rpcbind should not start by default. (+7,0,0) 17:40:36 i'll try to poke steved about this if he's in today as soon as we're done here. 17:40:50 kylem: we actually use v3 in infra, but we could switch to v4... and probibly should. 17:40:59 nirik, you should 17:41:04 :) 17:41:08 nirik, indeed. v4 is... superior. 17:41:13 changing this will also need a systemd bug to change the preset? 17:41:18 Of course it is. It's one higher! 17:41:29 well, everytime I have asked netapp folks they have said... meh. not really any different. 17:42:10 ok, moving on then... 17:42:19 #topic #1311 Disable syscall auditing by default 17:42:20 .fesco 1311 17:42:20 https://fedorahosted.org/fesco/ticket/1311 17:42:21 nirik: #1311 (Disable syscall auditing by default) – FESCo - https://fedorahosted.org/fesco/ticket/1311 17:42:26 there was a new comment just added to this. 17:42:59 that's unhelpful. ;-) 17:43:10 AFAICT nothing new in that comment anyway 17:43:17 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 oh yeah, we already decided here... 17:44:03 we can re-evaluate once we have extra data 17:44:16 dgilmore: can you update that ticket with agreement and plan? 17:44:48 nirik: yes sir 17:44:59 thanks. ;) 17:45:09 #info this was decided last week, will update ticket with info. 17:45:15 #topic #1318 shared-mime-info arbitration 17:45:16 .fesco 1318 17:45:16 https://fedorahosted.org/fesco/ticket/1318 17:45:17 nirik: #1318 (shared-mime-info arbitration) – FESCo - https://fedorahosted.org/fesco/ticket/1318 17:46:08 so, sounds like we have a good path for f21... 17:46:14 the question is what to do with f20 17:46:28 Kind of; there’s little hope of all the existing packages changing for F21 17:46:58 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 mitr, provenpackager could do that 17:47:34 if someone is willing to 17:47:34 mitr: when/if the guildelines get updated, I already offered to implement package scriptlet updates 17:47:46 rdieter: ah, great. 17:47:56 should be able to possibly script it. 17:47:57 so that part is not in dispute here 17:48:01 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 mitr, +1 17:49:19 I agree that the ship has sailed for f20 17:49:24 as for the F20 I agree that we should leave F20 as is 17:49:25 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 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 mitr: yes (which is what I do at my site, scratching my itch) 17:50:30 it helps subsequent package updates too, of course 17:50:41 i think getting to a point where we only call update-mime-database once per transaction is where we should be 17:50:42 True 17:51:05 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 rdieter: So this fix is going into f20 updates? 17:51:16 sgallagh: +1 17:51:16 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 sgallagh, +1 17:51:33 sgallagh: The FPC proposal depends on a new feature added to shared-mime-info 17:51:42 sgallagh: so, +1 to first part, -1 to "but" ATM 17:51:49 sgallagh: but not until the f20 one at least ignores the -n right? 17:51:52 rdieter: but when it effects install time and update tinme as drastically as it does now we should 17:52:09 dgilmore: yeah, definitely. no disagreement there 17:52:18 Perhaps I misread; I thought the fix was already (in progress of) being backported 17:52:35 sgallagh: it is in progress, yes 17:53:03 sgallagh: well, the backported fix is only that the new -n option will be accepted (and ignored) 17:53:08 yeah, so the only way to partially 'fix' f20, is a package that just drops the sync 17:53:10 the code is too different 17:53:12 ok 17:53:28 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 sgallagh: the only question for fesco here now, is: should it use fsync by default or not 17:53:56 abadger1999: I have the fix for f19 too, fwiw 17:53:59 * nirik suspects it may be a gotcha for f19 17:53:59 rdieter: F20 has been out long enough that I'd rather not risk destabilizing it, personally 17:54:22 sgallagh: frankly, theres ~0% chance of that 17:54:26 imho 17:54:43 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 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 So this is just creating a cache? 17:55:55 yes 17:56:20 * abadger1999 agrees with nirik's sentiment... 17:56:36 abadger1999: but a cache that is required to be present, and if corrupted the applications won’t magically ignore it 17:56:38 abadger1999: it's generating the stuff in /usr/share/mime/ from the /usr/share/mime/packages/ xml input 17:56:38 not sure if that makes me +1 or -1 to overruling, though. 17:56:51 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 of course we aren't. ;) 17:57:48 OK, to be more limited: are we doing installs and updates safely? (“of course we aren’t", yeah, well) 17:57:49 mitr: rpm payload can be verified at least 17:58:00 rdieter: ah, good point. 17:58:22 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 but users with corrupted ones may not know how to regen the cache or whats causing weird icons 17:58:56 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 they don't 17:59:27 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 (suddenly a “safe boot” that blows all caches and magically fixes some problems starts to look kinda smart) 17:59:51 hadess claimed there were real world crashes due to corruption, but I didnt get any answer asking for more details 17:59:53 The other way is there's bad performance in f20. We will just wait for f21 to optimize that. 18:00:18 abadger1999: More precisely, our hands for F20 are kinda tied. We can improve (yum update) and fairly custom installs, only. 18:00:49 with the -n backport also is the env variable to override the sync? 18:00:57 or that env is only f21+? 18:00:59 nirik: yes 18:01:09 the env variable is available 18:01:11 mitr: isn't install with update repositories still standard in anaconda? 18:01:46 again, the only issue at hand, is whether fsync is enabled, *by default* or not 18:01:49 mitr: if so, then it's not just fairly custom installs we could fix the regression for. 18:02:22 I guess I am slightly toward 'leave f20 alone' 18:02:44 do we want to vote here? or more questions/discussion? 18:03:17 proposal: FESCo doesn’t require the fdatasync() behavior in F20 shared-mimo info to be modified 18:03:22 (+1 for the record) 18:03:41 +1 18:03:42 +0.5... ok, +1 18:03:42 mitr: +1 18:03:47 +1 18:04:03 +1 from me as well, although there is performance regression i am ok fixing it in F21 only 18:04:13 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 me is 0 18:04:36 abadger1999: either I guess, but what I had in mind was in code 18:04:43 k 18:04:47 the result would be the same 18:05:29 On mitr's proposal, 0 if it's in code; -1 if it's set via the env var 18:05:44 #agreed FESCo doesn’t require the fdatasync() behavior in F20 shared-mimo info to be modified (+6,+2,0) 18:06:10 anything else on this? sorry rdieter... 18:06:24 no problem. that's all, I can go submit something to bodhi now. 18:06:42 thanks a lot for tracking this down and driving it forward. 18:06:46 I'll just keep a fork in my local site repo, cause I don't like waiting 18:06:47 #topic #1321 Can packages not approved for Fedora be placed in non-official branches of the Fedora pkgs repo? 18:06:47 .fesco 1321 18:06:47 https://fedorahosted.org/fesco/ticket/1321 18:06:48 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 I think the topic is slightly misleading 18:08:30 t8m: I don't think so -- but I do think that multiple things are being conflated in the ticket. 18:08:44 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 mattdm, +1 18:09:01 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 well, I made some suggestions, but no one answered. ;) 18:09:22 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 right now we can not remove any content from dist-git at all 18:09:58 abadger1999: That's really not a fair characterization of what is happening 18:10:02 we need some work to make sure builds are done from appropriate branches 18:10:08 dgilmore yeah _that_ seems like a big reason not to do this. 18:10:17 so people doing work in side branches ahve to leave it there 18:10:37 or can I check in the mingw version of my package that I have not submitted for review yet? 18:10:38 dgilmore, that seems like bug in koji though :) or a seriously needed feature 18:10:49 we want to get to a point where we can allow people to delete things used to experiment 18:10:58 t8m: its not a bug in koji 18:10:59 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 for the record I would love to enhance dist git. 18:11:12 nirik: I agree that we already provide fedorapeople git which is the clposest thing w ecurrently provide that fills this niche 18:11:15 t8m: its a bug in how dist-git was developed 18:11:20 and its never been fixed 18:11:43 #help we sure could use a lot of enhancements to our tools to support these ues cases 18:11:46 mitr: As I see it is. You can present an alternative and I can see where we're disagreeing though. 18:11:54 mattdm: indeed 18:12:29 I have concerns over poluting lookaside cache with this also 18:12:37 but we could do tooling to work around that 18:12:55 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 It’s not like anyone is committing chrome.spe in there 18:14:06 I guess the question is how much 'related' should something be. 18:14:29 mitr: Ah -- but that's still a very grey definition. mingw, scls, compat packages all fall in there. 18:14:50 new/nightly of exact same package? mingw version? python3 version? scl version? suse package?/ 18:14:55 abadger1999: As I said in the ticket, we allow arbitrary half-finished personal branches, so why not this? 18:15:03 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 mitr, +1 18:15:19 abadger1999, that is absurd 18:15:23 mitr: Of the same package or of different packages? 18:15:32 abadger1999 can you articulate the harm other than organizational cleanliness? 18:15:36 t8m: the second example? Or the first one? 18:15:44 (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 abadger1999, the last one 18:16:14 mitr: there is also lookaside storage 18:16:28 mitr: we never delete from lookasie 18:16:30 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 lookaside 18:16:35 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 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 if someone is pulling in nightly snapshots of a big upstream project that will quickly use up disk 18:17:08 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 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 t8m: patches welcome! :) 18:18:21 * nirik runs 18:19:05 I suppose: 18:19:07 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 one of the uses for these seems to be nightly builds... thats a lot of scm commits noise also 18:19:10 … 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 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 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 mitr: I could agree to that, but the devil is in the details of course. ;) 18:20:25 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 nirik: yeah, the above doesn't actually rule out having pkgs and pkgs-copr separate installations of the same software 18:20:48 but it does rule out some of the proposed alternatives like fedorapeople 18:20:59 mitr, +1 18:21:06 mitr: uhh... the way I read it, fedorapeople is okay. 18:21:13 abadger1999: could you dig up an exact link for the “list of things that need to change in our current tooling"? 18:21:15 mitr: long term sure... now, no? 18:21:45 mitr: last paragraph of the initial ticket description. 18:22:05 abadger1999: ah, thanks. 18:22:36 perhaps we could discuss now, short term and long term? 18:22:45 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 mitr: an option could be a second set of repos and seperate lookaside cache 18:23:09 it would tae some work to sort it out 18:23:27 and would need a new fedpkg like tool 18:23:48 abadger1999: impossibility to write tools that work with “all” packages 18:23:49 how much demand is there for this? 18:24:18 do we know? 18:25:27 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 nirik: Recently, there's been a flurry of these requests from a small team of people. 18:26:35 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 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 mitr: we do not GC lookaside. 18:27:05 compared to the entire packageset, probably not large, though. 18:27:14 kind of a squaky wheel? 18:27:14 nirik: i.e. there is no difference at this moment and no reason to split? 18:27:19 *squeeky 18:27:53 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 *pay 18:28:12 and all those sources are not things in official fedora packages, so it seems sad to use our disk for them. 18:28:19 mitr: separate lookaside means we could easily work out a way to clean old things out 18:28:20 actually plan. 18:28:46 dgilmore: thanks 18:28:47 mitr: but it would mean uploading things again when deciding its ready for fedora 18:29:32 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 nirik: +1 18:29:58 nirik, +1 18:30:00 nirik: +1 18:30:44 more votes? ;) or counterproposals? 18:31:10 I guess I'm +1. I wish we did have something better in place 18:31:16 but wishes and horses and all that :) 18:31:43 +1 18:31:48 -1; I’d rather have work-in-progress and notes and all sharable in there 18:32:03 -1 18:32:25 nirik: Would 18:32:27 proposal: Do not use pkgs dist-git for changes that require new lookaside-cache files for now. Work with …. 18:32:29 be acceptable? 18:32:48 That should address the primary costs at least 18:33:17 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 I don't think so... that doesn't address the other issues. 18:33:41 compat packages, mingw, etc. 18:34:03 or rather 0 as I understand that allowing anything (legally OK) in separate branches is a problem 18:34:07 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 cool. I can upload my backups to pkgs? ;) 18:35:09 \ó/ 18:35:34 nirik, encrypt them and upload to the lookaside. what could possibly go wrong 18:35:42 mitr: It's not "just a storage mechanism" by convention. As t8m wrote above about some examples being absurd shows 18:36:04 *sigh* So let me simplify, I just find the insistence on FPC reviews absurd. 18:36:18 mitr, +1 18:36:33 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 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 mitr, +1 18:37:38 nirik: Sorry, let’s move on then. I don’t want to be a pest about it. 18:37:42 substantially similar is likely the sticking point. 18:37:44 mitr: part of why things are as they are is to make things easy to find 18:38:01 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 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 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 #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 #topic 1320 Proposal: trivial patch policy 18:39:31 .fesco 1320 18:39:31 https://fedorahosted.org/fesco/ticket/1320 18:39:32 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 nirik: #1320 (Proposal: trivial patch policy) – FESCo - https://fedorahosted.org/fesco/ticket/1320 18:39:52 mitr: right now there is zero enforcement 18:39:54 mitr: right now, you can build from any git hash 18:40:39 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 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 but never mind 18:42:13 Or we could temporarily prohibit the use of other branches unless someone wants them badly enough to write the enforcement patch? 18:42:25 (re: #1320, all I wanted to say is in comment:1) 18:42:35 mitr: thats what we did isn't it? 18:42:44 mitr: anyone with access can create a push a branch, we just cant delete it 18:42:57 I'm +1 to #1320. It seems like a nice step forward. 18:43:07 nirik: I didn’t read it like that, good point. 18:43:26 re, 1320 im +1 but i agree it could hide issues when dealling with ftbfs packages 18:43:40 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 +1 for the record 18:43:58 +1 18:44:31 +1 with the same reservations as dgilmore and scop. 18:44:45 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 thats +6... any other votes? do we want to adjust anything for the ftbfs concern? 18:45:35 smani: I would hope provenpackagers would use good judgement in refusing things that are not approprate... 18:45:53 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 yep. our inactive policy needs a complete rewrite. We have a lot more info than we used to... 18:46:53 i know we have had to fix some ftbfs on primary to unblock other things on secondary arches 18:47:10 we should be able to count the number of bugs for a certain package which block the tracker 18:47:29 that number gives us _more_ information on inactive maintainers than just ftbfs 18:47:42 theres a lot of info we could put together on maintainers and on specific packages. 18:48:04 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 maintainers: last commit, last fas login, last mailing list post, last build, last fedmsg of any kind related to them, etc. 18:48:29 which in itself is not necessariy a problem but with linger bug reprts etc is 18:48:30 packages: last commit by packager X, last commit at all, last build, last qa results, number of updates, etc etc 18:48:46 anyhow... thats drifting into another topic. 18:48:52 nirik: right 18:48:59 if a certain package has had N "spp" bugs against it in a year, flag it... 18:49:04 didn't we have a separate ticket for this? 18:49:07 #agreed policy is approved (+6,0,0) 18:49:11 t8m: yeah 18:49:22 so i think ftbfs fixes is kinda a concern in masking things and maybe keeping things in that should be removed 18:49:31 thanks for working on this smani. Can you setup the tracker bug and add the policy to the wiki, etc? 18:49:39 but i wouldnt make it a blocker on getting people to help fix simple issues 18:50:11 nirik: yes will do so 18:50:30 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 smani: cool. let me know if I can assist with any of it. 18:50:55 #topic Next week's chair 18:51:00 who wants the hot potatoe? 18:51:15 nirik: ok! 18:51:30 * sgallagh might not make it next wek. 18:51:33 *week 18:51:35 I think it's probably about my turn :) 18:51:44 cool. Thanks 18:51:50 #info mattdm to chair next week 18:51:53 #topic Open Floor 18:52:01 anyone have anything for open floor? 18:52:33 nirik: quick back track to the first topic 18:52:45 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 im likely going to spend the week of July 28 in brno 18:52:55 dgilmore: oh yeah, whats your plans? 18:54:01 ok, then you are ok with sticking to schedule? 18:54:16 i still need to make them but right now im planning to be in Brno July-28 through August 5 18:54:24 yep i am 18:54:53 cool. 18:56:16 ok, if nothing else will close in a minute or less. 18:56:34 thanks very much nirik. 18:56:42 fwiw, i'll be on PTO for the next two meetings. :/ 18:56:57 ok, hopefully going somewhere fun. ;) 18:57:00 shortest fesco tenure ever. ;-) 18:57:18 :) 18:57:23 ok, thanks for coming everyone. 18:57:25 #endmeeting