meetingminutes July 2014

meetingminutes@lists.fedoraproject.org

21 participants
60 discussions

APAC ambassadors meeting (07-05-2014) minutes
by Mohan Prakash 05 Jul '14

05 Jul '14

Hi Only two people showed up and there was nothing to discuss, so there was not much of a meeting, however I'm sending the logs and minutes for records. minutes (html): http://meetbot.fedoraproject.org/fedora-meeting/2014-07-05/apac_ambassadors… minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2014-07-05/apac_ambassadors… log: http://meetbot.fedoraproject.org/fedora-meeting/2014-07-05/apac_ambassadors… -------------------------------------------------------------------------- #fedora-meeting Meeting -------------------------------------------------------------------------- Meeting started by mpduty_ at 04:06:16 UTC (full logs). Meeting summary rollcall (mpduty_, 04:07:18) Meeting ended at 04:28:35 UTC (full logs). Action items (none) People present (lines said) mpduty_ (21) somvannda (9) zodbot (4) --------------------------------------------------------------------------------- regards Mohan fas name: mohanprakash IRC nick: mpduty

1 0

FAMNA Meeting 07-03-2014
by Andrew Ward 04 Jul '14

04 Jul '14

Please review note our meeting from 3 July 2014 Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2014-07-04/famna.2014-07-04… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2014-07-04/famna.2014-07-04… Log: http://meetbot.fedoraproject.org/fedora-meeting/2014-07-04/famna.2014-07-04… -- Andrew Ward award3535(a)fedoraproject.org award3535(a)tds.net award3535(a)gmail.com

1 0

Summary/Minutes from today's Fedora Infrastructure meeting (2014-07-03)
by Kevin Fenzi 03 Jul '14

03 Jul '14

============================================ #fedora-meeting: Infrastructure (2014-07-03) ============================================ Meeting started by nirik at 18:00:22 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/infrastructure.2… . Meeting summary --------------- * aloha (nirik, 18:00:23) * New folks introductions and Apprentice tasks (nirik, 18:01:48) * Applications status / discussion (nirik, 18:04:49) * LINK: http://apps.fedoraproject.org/kerneltest is in prod (pingou, 18:05:29) * kerneltest is close to ready. Needs just fedmsg notifications sorted out. (nirik, 18:07:16) * new pkgdb2 in stg. (nirik, 18:07:25) * taskotron-dev is almost ready to use. stg to follow soon. (nirik, 18:08:45) * Sysadmin status / discussion (nirik, 18:10:57) * some more rhel7 instances re-installed this last week. (nirik, 18:11:15) * fixed httpd logs to rotate as we want in ansible and sync to log02 again (nirik, 18:12:56) * nagios/alerts recap (nirik, 18:16:48) * Upcoming Tasks/Items (nirik, 18:19:30) * LINK: https://apps.fedoraproject.org/calendar/list/infrastructure/ (nirik, 18:19:30) * Open Floor (nirik, 18:24:09) Meeting ended at 18:33:32 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (72) * pingou (16) * smooge (8) * zodbot (5) * kushal (4) * lalit_ (4) * ootbro (3) * selvakumarm (3) * hammad_ (3) * mirek-hm (3) * tflink (2) * lanica (2) * lmacken (2) * lobocode (1) * abadger1999 (1) * bwood09 (1) * randomuser (1) * oddshocks (1) * threebean (0) * relrod (0) * mdomsch (0) * puiterwijk (0) * dgilmore (0) -- 18:00:22 <nirik> #startmeeting Infrastructure (2014-07-03) 18:00:22 <zodbot> Meeting started Thu Jul 3 18:00:22 2014 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:23 <nirik> #meetingname infrastructure 18:00:23 <nirik> #topic aloha 18:00:23 <nirik> #chair smooge relrod nirik abadger1999 lmacken dgilmore mdomsch threebean pingou puiterwijk 18:00:23 <zodbot> The meeting name has been set to 'infrastructure' 18:00:23 <zodbot> Current chairs: abadger1999 dgilmore lmacken mdomsch nirik pingou puiterwijk relrod smooge threebean 18:00:28 * bwood09 is here 18:00:35 <smooge> gere 18:00:35 * lmacken 18:00:42 * lalit_ is here 18:00:50 * tflink 18:00:56 <selvakumarm> is here 18:00:59 * lanica is here for infra meeting. 18:01:00 <ootbro> dazed and confused, but here (and so far no seeing anything from Arthur) 18:01:43 <abadger1999> óla 18:01:48 <nirik> #topic New folks introductions and Apprentice tasks 18:02:03 <nirik> any new folks like to give a short introduction of themselves? 18:02:06 <selvakumarm> I am Selva (New Joiner). Basically solution architect profession and specialized in linux administration and perl scripting. Interesting in the same with Nagios in our group. Looking for sponsor !! 18:02:08 * pingou 18:02:09 <nirik> or apprentices with questions, comments or status? 18:02:28 <nirik> welcome selvakumarm. 18:02:48 <ootbro> I'll save the rest of my questions 'til afterwards ;) :P 18:03:09 <nirik> selvakumarm: see me after the meeting in #fedora-admin and we can point you to our apprentice group and tickets to look into... 18:03:16 <nirik> ootbro: fair enough. :) 18:03:19 * randomuser adopts his usual lurking posture 18:03:31 <selvakumarm> sure nirik 18:04:05 <nirik> cool. any other new folks? 18:04:49 <nirik> #topic Applications status / discussion 18:04:58 <pingou> new pkgdb2 in stg: https://admin.stg.fedoraproject.org/pkgdb/ 18:04:58 <nirik> any applications news this week or upcoming? 18:05:02 <pingou> testers welcome :) 18:05:14 <pingou> and there will be a new pkgdb-cli released soon 18:05:29 <pingou> http://apps.fedoraproject.org/kerneltest is in prod 18:05:46 <pingou> and already populated with 4901 test results 18:05:53 <nirik> excellent. There was something related to fedmsg's to fix on kerneltest? 18:06:01 <nirik> or did threebean fix that already? 18:06:16 <pingou> I think he fixed 2 SELinux related issue 18:06:49 <pingou> but iirc he still needed some debugging (so I think it wasn't there yet) 18:06:54 <nirik> yeah. ok 18:07:16 <nirik> #info kerneltest is close to ready. Needs just fedmsg notifications sorted out. 18:07:25 <nirik> #info new pkgdb2 in stg. 18:07:26 <lmacken> for anyone looking to write a quick patch, we could add the new kerneltest app to https://github.com/fedora-infra/apps.fp.o 18:07:37 <nirik> yes indeed. 18:07:38 <pingou> #easyfix :) 18:07:48 <nirik> we also need to add kerneltest* machines to nagios. 18:08:10 <tflink> taskotron-dev is close to being done, stg to follow soon thereafter 18:08:17 <pingou> tflink: cool! 18:08:24 * mirek-hm is here 18:08:45 <nirik> #info taskotron-dev is almost ready to use. stg to follow soon. 18:09:38 * oddshocks is here 18:10:10 <nirik> ok, anything else app wise? 18:10:57 <nirik> #topic Sysadmin status / discussion 18:11:04 <nirik> lets see... on the sysadmin side... 18:11:15 <nirik> #info some more rhel7 instances re-installed this last week. 18:11:48 <nirik> I didn't get too much ansible migration done, but I did get a bunch of cleanup on our ansible playbooks done 18:12:06 <nirik> we now have a master.yml top level playbook that includes all our host/group ones. 18:12:31 <nirik> this is useful if you change something in the base role or fedmsg/base or something that lots of instances use, you can run that with '-t tagname' and it will just apply those changes all round 18:12:56 <nirik> #info fixed httpd logs to rotate as we want in ansible and sync to log02 again 18:13:23 <nirik> I also setup some ansible groups for our hardware, so we can run commands to see firmware versions or whatever over all dells for example 18:14:11 <lanica> Cool 18:14:13 <nirik> smooge: can you think of anything else this week? you were working on the new osuosl machine and it ran into a switch port issue. 18:14:32 <smooge> no I have basically been banging on that 18:14:46 <nirik> yeah, sorry it's been such a pain. 18:14:52 <smooge> meh.. its not PPC 18:15:01 * hammad_ is here 18:15:12 <nirik> oh, speaking of... any word back on that ppc-comm04 box with the broken power supply/fans? 18:15:44 <smooge> I didn't hear anything from IBM. 18:15:50 <nirik> hum. ;( 18:16:05 <smooge> so I will call and start the usual passive aggressive proces 18:16:07 <nirik> oh well, we will keep bugging em. 18:16:08 <nirik> yeah. 18:16:24 <nirik> I'm also in the coming weeks going to try and move stuff off telia01. 18:16:36 <nirik> it's very slow network wise and I am tired of the alerts. ;) 18:16:45 <nirik> which brings us to: 18:16:48 <nirik> #topic nagios/alerts recap 18:17:13 <nirik> .tiny https://admin.fedoraproject.org/nagios/cgi-bin//summary.cgi?report=1&displa… 18:17:13 <zodbot> nirik: http://tinyurl.com/q8j48o9 18:17:20 <nirik> been a somewhat quiet week. 18:17:35 <nirik> packages03 has been hitting high memory, not sure why. 18:17:53 <nirik> log02 also has, but thats collectd. Might be the new rhel7 hosts sending it data it can't grok 18:18:16 <smooge> I will be working on log01 on one of the new virthosts 18:18:19 <nirik> serverbeach07 was me reinstalling it and it dropping off the net and needing rescue mode 18:18:33 <smooge> unless someone wants to take that 18:18:35 <nirik> the rest are largely the usual telia network 18:19:30 <nirik> #topic Upcoming Tasks/Items 18:19:30 <nirik> https://apps.fedoraproject.org/calendar/list/infrastructure/ 18:19:51 <nirik> anything upcoming anyone would like to schedule or note? 18:20:04 <pingou> shiny auto-scolling :) 18:20:06 <nirik> smooge and I will be out at phx2 datacenter toward the end of the month 18:20:27 <nirik> also tomorrow is a holiday in the us... so many us folks will not be near their computers. 18:20:42 <pingou> enjoy the day of the movie :) 18:20:47 <nirik> heh 18:20:58 <mirek-hm> I will be on vacation next week, I gave access to copr to Adam Samalik, who co-develop it with me, so he may fix it if there will be some problem. 18:21:02 <nirik> then in early aug, many folks will be heading to flock. 18:21:14 <nirik> mirek-hm: sounds good. are they on irc any? 18:22:00 <mirek-hm> nirik: good point, i will tell him to join fedora-admin and buildsys 18:22:09 <nirik> cool. 18:23:16 <nirik> also, we have our first f21 freeze coming up. 18:23:31 <nirik> amusingly starting when smooge and I are out at the datacenter. Oops. 18:24:09 <nirik> #topic Open Floor 18:24:17 <nirik> anyone have items for open floor? questions, comments? 18:24:45 <smooge> oh well I expect alpha will be a very long stretch 18:24:52 <pingou> there is the transifex question that poped-up on the list 18:24:55 <nirik> yeah, could well be. 18:25:09 <nirik> pingou: yeah, not sure what to do there. ;( 18:25:43 <hammad_> Hello, I am hammad, working on fedora-college. I was not able to attend last weeks meeting. We have almost done (halfway) with the initial prototype for the product. Have a look http://demo.engineerinme.com. 18:25:45 <nirik> really in our scope that just means for websites and our apps we are upstream for right? 18:25:55 <nirik> hey hammad_. welcome. 18:25:59 <pingou> nirik: my problem is that I don't know of any real alternative :( 18:26:15 <pingou> nirik: indeed 18:26:20 <pingou> (for the scope) 18:26:40 <nirik> yeah, zanata is free I think... but not packaged, java and jboss and things we have 0 people who are active in 18:26:54 <nirik> hammad_: will take a look at it. 18:27:15 <hammad_> Thanks :) 18:27:33 <kushal> Is there any other gsoc student here? 18:28:19 <nirik> kushal: last week we have a bunch. ;) 18:28:49 <kushal> nirik, yeah, but they are supposed to report each week :( 18:29:08 <kushal> and no one asks for enough input from infra team. 18:29:15 <lalit_> I am currently working bookmarking channel logs in waartaa(my gsoc project) 18:29:19 <lobocode> o/ 18:29:53 <lalit_> I have written some front end code as of now: https://github.com/D-Ne0/waartaa/commit/fb77930cd69d7fe61a8673f8e4ccf561a9b… 18:30:23 <lalit_> I targeting to complete it by this weekend 18:30:36 <nirik> cool 18:31:39 <nirik> ok, anything else for open floor? 18:32:08 <ootbro> Happy Fourth to all in the U.S. (and Phillipines) 18:32:28 <nirik> :) 18:32:36 <kushal> :) 18:32:37 <nirik> ok, if nothing else will close out in a minute... 18:33:28 <nirik> ok, thanks for coming everyone! 18:33:32 <nirik> #endmeeting

1 0

Summary/Minutes from today's irc support sig meeting (2014-07-03)
by Kevin Fenzi 03 Jul '14

03 Jul '14

============================================= #fedora-meeting: IRC Support SIG (2014-07-03) ============================================= Meeting started by nirik at 17:00:21 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/irc-support-sig.… . Meeting summary --------------- * init process (nirik, 17:00:21) * Week in review (nirik, 17:02:34) * Open Floor (nirik, 17:05:40) Meeting ended at 17:14:20 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (14) * zodbot (3) * Southern_Gentlem (2) * Khaytsus (1) -- 17:00:21 <nirik> #startmeeting IRC Support SIG (2014-07-03) 17:00:21 <zodbot> Meeting started Thu Jul 3 17:00:21 2014 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:21 <nirik> #meetingname irc-support-sig 17:00:21 <zodbot> The meeting name has been set to 'irc-support-sig' 17:00:21 <nirik> #topic init process 17:00:36 * Khaytsus 17:01:43 * Southern_Gentlem 17:02:28 <nirik> alright. Not too much agenda today 17:02:34 <nirik> #topic Week in review 17:02:57 <nirik> anyone have items from the channel? common bugs people are hitting, issues, types of requests, etc? 17:04:05 <nirik> nothing really stands out to me... just the usual stuff. 17:05:40 <nirik> #topic Open Floor 17:05:45 <nirik> anyone have anything for open floor? 17:06:02 <nirik> should we continue to meet bi-weekly? or are there things we should actually be trying to do? ;) 17:08:51 * nirik will wait a few more minutes then close. 17:10:32 <Southern_Gentlem> meet bi-weekly if there is something needed to meet about 17:14:13 <nirik> right. 17:14:17 <nirik> ok, thanks everyon. 17:14:20 <nirik> #endmeeting

1 0

Summary/Minutes from today's FPC Meeting (2014-07-03 16:00 - 17:00 UTC)
by James Antill 03 Jul '14

03 Jul '14

====================== #fedora-meeting-1: FPC ====================== Meeting started by abadger1999 at 16:04:36 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2014-07-03/fpc.2014-07-03… . Meeting summary --------------- * Roll Call (abadger1999, 16:04:44) * #339 software collections in Fedora (abadger1999, 16:11:08) * LINK: https://fedoraproject.org/wiki/User:Toshio/SCL_Macros_Change (abadger1999, 16:21:21) * Proposal: SCL packages must be separate packages, not separate branches in the git repos (+1: 4, 0:1, -1:0) Seeking more votes in ticket (abadger1999, 16:27:43) * https://fedoraproject.org/wiki/User:Toshio/SCL_Macros_Change which makes for strict separation between mainstream and SCLized packages (+1:5, 0:0, -1:0) (abadger1999, 16:40:40) * #382 Go Packaging Guidelines Draft (abadger1999, 16:41:26) * #414 Please consider requiring AppData for all desktop (abadger1999, 16:41:55) * #419 ruby193 in SCL (abadger1999, 16:43:14) * LINK: https://fedorahosted.org/fpc/ticket/419 (abadger1999, 16:43:19) * #435 %py3dir not removed by rpmbuild --clean (abadger1999, 16:45:38) * #439 update for Packaging:Tmpfiles.d (abadger1999, 16:45:56) * LINK: https://fedorahosted.org/fpc/ticket/439 (abadger1999, 16:46:01) * #440 mimeinfo scriptlet update (abadger1999, 16:46:47) * LINK: https://fedorahosted.org/fpc/ticket/440 (abadger1999, 16:46:51) * mimeinfo scriptlet update (+1:4, 0:0, -1:0) Will seek additional vote in ticket (abadger1999, 16:54:40) * Bundled Library exception request for Gazebo (abadger1999, 16:54:59) * LINK: https://fedorahosted.org/fpc/ticket/317 (abadger1999, 16:55:04) * Approve 317 as forking rather than bundling: (+1:4, 0:0, -1:0) Will seek more votes in ticket (abadger1999, 17:02:31) * #440 mimeinfo scriptlet update (abadger1999, 17:02:44) * EDIT: mimeinfo scriptlet update PASSED (+1:5, 0:0, -1:0) (abadger1999, 17:02:50) * Open Floor (abadger1999, 17:02:54) * EDIT: Approve 317 as forking rather than bundling: APPROVED (+1:5, 0:0, -1:0) (abadger1999, 17:04:28) Meeting ended at 17:05:47 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * abadger1999 (111) * geppetto (24) * tibbs|w (10) * racor (9) * langdon (9) * zodbot (8) * Rathann (8) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

divulgacion fudcon
by Neville A. Cross 03 Jul '14

03 Jul '14

Comenté que deberiamos enfocar los siguientes contenidos: 1.- wiki de fedora: logistica 2.- fudcon latam: trabajo local del evento 3.- roadtofudconlatam: información de avances de cara al resto del mundo e información para invitados. eso solo es una idea, pero hay que crear el contenido ... pensaba trabajar en ello el domingo. Alguien tiene tiempo? Mañana? tarde? -- Neville https://fedoraproject.org/wiki/User:Yn1v Linux User # 473217

1 0

Cloud SIG Meeting Minutes for 2014-07-03
by Haïkel 03 Jul '14

03 Jul '14

Hello, The Cloud WG was able to held its weekly meeting despite summer :) You'll find below the minutes and the logs of the meeting ========================= #fedora-meeting: Cloud WG ========================= Meeting started by number80 at 14:10:58 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/fedora-meeting.2… . Meeting summary --------------- * Hello everyone (number80, 14:11:34) * Working Group (number80, 14:14:29) * Automatic Smoketests on Image Build (number80, 14:16:17) * taskotron moving toward production and replacing AutoQA soon (number80, 14:17:34) * roshi working on fabric-based test suite for cloud images (number80, 14:19:34) * Deliverables and release engineering changes for Fedora.Next (number80, 14:22:31) * LINK: https://fedorahosted.org/cloud/ticket/50 (number80, 14:22:37) * changes freeze is scheduled on 2014/07/08 (number80, 14:23:59) * ACTION: jzb ticket 50: https://fedorahosted.org/cloud/ticket/50 (jzb, 14:24:23) * start communication/collaboration on cloud image updates (number80, 14:25:45) * ACTION: mattdm to keep moving this forward; agrimm to help (mattdm, 14:38:01) * Docker image (number80, 14:41:14) * dgilmore and jgreguske are working on updating koji to support docker images creation (number80, 14:42:28) * ACTION: mattdm to ping lsm5 about that too (as he is the feature owner) (mattdm, 14:43:57) * LINK: https://fedorahosted.org/cloud/ticket/65 (number80, 14:44:12) * Project Atomic (number80, 14:46:58) * LINK: https://fedorahosted.org/cloud/ticket/64 (number80, 14:47:03) * ACTION: agrimm is helping on ticket 64: https://fedorahosted.org/cloud/ticket/64 (number80, 14:50:04) * looking for integrating of ostree trees into fedora infrastructure (number80, 14:52:45) * ACTION: jzb trying to setup a cantas instance for the cloud SIG (number80, 14:58:47) * next steps on test plan (number80, 15:00:22) * LINK: https://fedorahosted.org/cloud/ticket/61 (number80, 15:00:24) * adamw is syncing all tests docs from all WGs (number80, 15:01:32) * open floor (number80, 15:04:14) * ACTION: number80 organize the vote to welcome agrimm in the WG (number80, 15:07:47) Meeting ended at 15:12:17 UTC. Action Items ------------ * jzb ticket 50: https://fedorahosted.org/cloud/ticket/50 * mattdm to keep moving this forward; agrimm to help * mattdm to ping lsm5 about that too (as he is the feature owner) * agrimm is helping on ticket 64: https://fedorahosted.org/cloud/ticket/64 * jzb trying to setup a cantas instance for the cloud SIG * number80 organize the vote to welcome agrimm in the WG Action Items, by person ----------------------- * agrimm * mattdm to keep moving this forward; agrimm to help * agrimm is helping on ticket 64: https://fedorahosted.org/cloud/ticket/64 * number80 organize the vote to welcome agrimm in the WG * jzb * jzb ticket 50: https://fedorahosted.org/cloud/ticket/50 * jzb trying to setup a cantas instance for the cloud SIG * mattdm * mattdm to keep moving this forward; agrimm to help * mattdm to ping lsm5 about that too (as he is the feature owner) * number80 * number80 organize the vote to welcome agrimm in the WG * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * number80 (87) * jzb (37) * mattdm (35) * roshi (22) * agrimm (21) * zodbot (12) * dgilmore (7) * frankieonuonga (6) * jsmith (2) * geppeto (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/fedora-meeting.2… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/fedora-meeting.2… Log: http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/fedora-meeting.2…

1 0

LATAM regional meeting minutes
by Neville A. Cross 03 Jul '14

03 Jul '14

It was agreed to keep open latinoware request until July 9th, to give the remainder funds of the flock allocation to cover hotel for echevemaster and to sponsor some events in Nicaragua Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2014-07-02/latam_ambassador… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2014-07-02/latam_ambassador… Log: http://meetbot.fedoraproject.org/fedora-meeting/2014-07-02/latam_ambassador… -- Neville https://fedoraproject.org/wiki/User:Yn1v Linux User # 473217

1 0

Summary/Minutes from today's FESCo Meeting (2014-07-02)
by Kevin Fenzi 02 Jul '14

02 Jul '14

=================================== #fedora-meeting: FESCO (2014-07-02) =================================== Meeting started by nirik at 17:00:27 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-07-02/fesco.2014-07-02… . Meeting summary --------------- * init process (nirik, 17:00:27) * #1178 Fedora 21 scheduling strategy (nirik, 17:03:39) * LINK: https://fedorahosted.org/fesco/ticket/1178 (nirik, 17:03:40) * 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 (nirik, 17:17:16) * 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) (sgallagh, 17:26:45) * 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 (nirik, 17:32:15) * AGREED: rpcbind should not start by default. (+7,0,0) (nirik, 17:40:33) * #1311 Disable syscall auditing by default (nirik, 17:42:19) * LINK: https://fedorahosted.org/fesco/ticket/1311 (nirik, 17:42:20) * this was decided last week, will update ticket with info. (nirik, 17:45:09) * #1318 shared-mime-info arbitration (nirik, 17:45:15) * LINK: https://fedorahosted.org/fesco/ticket/1318 (nirik, 17:45:16) * 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 (nirik, 18:06:47) * 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 (nirik, 18:39:31) * 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 ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) 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' <sgallagh(a)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(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 - 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

1 0

FAmSCo meeting minutes 2014-07-01
by Jiri Eischmann 01 Jul '14

01 Jul '14

Hi, we had another regular FAmSCo meeting, 4 members attended. You can find more in the minutes: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-2/2014-07-01/famsco.2014-07… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-2/2014-07-01/famsco.2014-07… Log: http://meetbot.fedoraproject.org/fedora-meeting-2/2014-07-01/famsco.2014-07… The next meeting will be on July 8th. Jiri

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

meetingminutes July 2014