09:06:38 #startmeeting 09:06:38 Meeting started Tue Aug 2 09:06:38 2016 UTC. The chair is nardasev. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:06:38 Useful Commands: #action #agreed #halp #info #idea #link #topic. 09:06:38 The meeting name has been set to '' 09:06:50 #meetingname flock2016 09:06:50 The meeting name has been set to 'flock2016' 09:07:10 getting something new into Fedora 09:07:18 what is 'something'? 09:07:35 NOT an RPM or a Spin 09:08:08 could be nodejs, rubygem, maven repo, new format for installer image, new container format 09:08:15 if I have a new thing: 09:08:28 talk to release engineering EARLY! 09:08:46 work in the open and engage others for feedback 09:08:58 do not rely on others to do work for you 09:09:30 people have a tendency to create their own wonderful thing 09:09:39 and then others are like, oh... 09:09:48 so you need to keep things open 09:10:59 today it is a bit tricky to do all the pieces of releasing on your own 09:11:06 but we want to make it easier 09:11:43 we make fedora using a set of tools and processes 09:11:53 we build and ship fedora as a unit 09:12:08 PDC is a single source of data about composes and releases 09:12:48 we are looking at automation currently 09:13:05 the 2-week Atomic compose is just a subset of all the pieces in Fedora 09:13:16 PDC is new in Fedora 24 09:13:33 PDC says what is in a compose in a release 09:13:42 you need to be able to reproduce 09:14:09 the build/compose environment needs to be reproducable 09:14:21 reasons for reproducibility: 09:14:32 we know what we went into, how it was made 09:15:03 and that enables us to have security certifications 09:15:18 so it helps the security team 09:15:34 it lets us say definitively what is shipped, when and how 09:15:57 it also enables accountability 09:16:11 the package maintainer is accountable for what went into it 09:16:44 if somebody does something wrong, we can easily go and get that 09:16:59 that applies especially for all new things in Fedora 09:17:20 next: 09:17:34 what we ship needs to be definable 09:17:47 we can't reproduce what we don't know 09:17:58 it lets us understand the pieces 09:18:14 FESCo, QA and releng know it is being done 09:18:33 if QA don't know what they need to test.. how can we ensure what we ship? 09:18:48 FESCo as the technical arbitrator needs to know what is being done 09:19:21 we hope that Fedora name has a certain quality attached to it 09:19:31 which is what we want to keep and improve 09:20:02 we want people to trust Fedora 09:20:06 next: 09:20:13 it needs to be deliverable 09:20:32 official parts of Fedora are eligible to be delivered to locations in /pub 09:21:14 Infrastructure and releng manage 1) mirror manager to distribute requests to hosts; 2) there is no CDN for deliverable 09:21:42 we have this mirror network which is getting more powerful and able to deliver more stuff 09:22:05 two years ago, we were just under 1 TB 09:22:23 now we are at 1.4 - 1.5 TB 09:22:39 ostree doesn't know how to use mirror 09:24:24 we need to have some mirror integration 09:25:30 Q: if I have a cool new thing, do I need to use mirrors or can I use best effort in Atomic? 09:25:51 A: we don't need to use mirrors from day 1, but we need to have a plan 09:26:20 how we deliver stuff really depends on what it is 09:26:28 live CD doesn't need mirror managers 09:26:38 because the users manually get it 09:27:09 but when you deal with tooling, you want to have multiple mirrors in case one of them fails 09:27:16 in the case of modules coming up 09:27:29 we have to figure out how mirroring is going to work 09:27:49 people are still focused on building the module itself 09:28:02 Fedora doesn't have the budget for CDN 09:28:29 we have a CDN that has been donated to us, but we heard that if you send too much traffic to them, they will reject and kick you out 09:28:44 so we can only use it in small scales 09:29:04 as much as the technology how you build and ship it is important, dealing with people is a critical step 09:29:07 SUMMARY: 09:29:14 talk, communicate, and work with us 09:29:21 be open and transparent 09:30:59 the main reason that made me submit this talk: 09:31:50 even if you have a great and successful project, it still needs to be integrated in the process of how we compose Fedora as a whole 09:32:14 if you start solving this at the beginning, it gets much harder later 09:32:20 which happened with Atomic 09:32:46 correction: if you DON'T start solving this at the beginning... 09:33:29 showing a graph of evolution of packages in fedora releases 09:33:52 fedora 7 had around 5000 RPM packages 09:34:04 it's been growing of course 09:35:27 i think modularity will help keep metadata smaller 09:37:21 release engineering has historically been under-resourced 09:37:35 people keep saying "we're going to work with you and talk to you" 09:37:50 question time. 09:38:55 having a native ruby gem repo is easier for a developer to deliver his code 09:39:50 having repos for different versions of Python, etc 09:40:27 if you have several versions of Fedora using a certain version of Python, you can install the particular repo in all the fedoras 09:40:56 there are only speculations 09:42:09 a new trademark will be made for a new repository 09:42:17 it's a new way for people to build things 09:42:43 build ostree is enabled from components in Fedora itself, but it's not an official Fedora delivery 09:43:03 a presentation about how NOT to deliver things into Fedora would be helpful 09:43:17 the delivery process is hard to grasp 09:43:35 and even harder for someone outside of the Fedora infrastructure 09:44:27 it is just as hard to add a new functionality into Koji 09:47:21 we use a containerized environment 09:48:32 we're struggling to keep up with everything 09:49:00 Q: how often do you talk to upstream developers of DNF and RPM? 09:49:18 A: dnf- not as often as we should, RPM much more often 09:49:46 but there is not enough ongoing communication 09:50:15 Q: how about features that would make your lives easier, are you trying to prioritize them? 09:50:20 A: it could be better :) 09:50:54 #endmeeting