Summary/Minutes from today's Fedora Infrastructure meeting (2014-07-03)
by Kevin Fenzi
============================================
#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...
.
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&disp...
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/fb77930cd69d7fe61a8673f8e4ccf561a...
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
9 years, 9 months
Summary/Minutes from today's irc support sig meeting (2014-07-03)
by Kevin Fenzi
=============================================
#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-si...
.
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
9 years, 9 months
Summary/Minutes from today's FPC Meeting (2014-07-03 16:00 - 17:00 UTC)
by James Antill
======================
#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-...
.
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
9 years, 9 months
divulgacion fudcon
by Neville A. Cross
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
9 years, 9 months
Cloud SIG Meeting Minutes for 2014-07-03
by Haïkel
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...
.
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...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/fedora-meeting...
Log:
http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/fedora-meeting...
9 years, 9 months
Summary/Minutes from today's FESCo Meeting (2014-07-02)
by Kevin Fenzi
===================================
#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-...
.
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
9 years, 9 months
