NixOS 18.09 release managers

Video thumbnail (Frame 0) Video thumbnail (Frame 2370) Video thumbnail (Frame 10065) Video thumbnail (Frame 17690) Video thumbnail (Frame 28322) Video thumbnail (Frame 28817) Video thumbnail (Frame 29436)
Video in TIB AV-Portal: NixOS 18.09 release managers

Formal Metadata

Title
NixOS 18.09 release managers
Title of Series
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2018
Language
English

Content Metadata

Subject Area
Abstract
The release managers talking about the latest NixOS release
Data management Statistics Bit Number
Point (geometry) Laptop Statistics Presentation of a group Multiplication sign Open set Counting Disk read-and-write head Software as a service Number Wiki Exact sequence Mathematics Core dump Videoconferencing Series (mathematics) Angular resolution World Wide Web Consortium Distribution (mathematics) Graph (mathematics) File format Software developer Graph (mathematics) Bit Maxima and minima Line (geometry) Process (computing) Software Personal digital assistant Data Encryption Standard Musical ensemble Sinc function
Sensitivity analysis 1 (number) Similarity (geometry) Branch (computer science) Web browser Software bug Frequency Mathematics Graphical user interface Kernel (computing) Software Cuboid Information security Stability theory Distribution (mathematics) Focus (optics) Patch (Unix) Bit Mathematics Graphical user interface Kernel (computing) Software Integrated development environment Revision control Cycle (graph theory) Information security Arithmetic progression
Scripting language Service (economics) Decision theory Patch (Unix) Multiplication sign Branch (computer science) Mereology Attribute grammar Software bug Revision control Mathematics Graphical user interface Bit rate Software Information security Overlay-Netz Email Inheritance (object-oriented programming) Patch (Unix) Surface Electronic mailing list Code Bit Cartesian coordinate system Graphical user interface Data management Software Personal digital assistant Network topology Revision control Kerr-Lösung Right angle Cycle (graph theory) Whiteboard Information security Table (information) Arithmetic progression Sinc function
Mathematics Bit Rule of inference
Multiplication sign
okay hello so so here's a similar the new release manager now right so it's the new release manager like the upcoming one where I'm handing over the management to him continually and well first we'll again show just a bit of some statistics similarly to what you might have seen on last Nick scorn but yeah well though they haven't really changed that much since they're well you can see like like on the whole the activity is continually rising you can see this for example on the number of issues that are created like the last year isn't complete yet so it's still still growing when compared to last year last year's 2017 well about their
software sorry the point was about there
when the presentation was made so if we compare we are already over what last year's amount of issues open at the same time so we're probably going to overshoot the number of issues opened last year for this year next the number of issues by user it's pretty similar to what was last year the top three is the same top three as last year I don't know if there's any such surprise since it's not the issues open since since that series since forever so the core temp and PTI will need to work a bit more if you they want to be on the top three but pretty much every other names just switch around in there and the same happen for the number of issues by assignee the top two I believe was the same the last one L&L seven was the same but in the middle there were some changes some places switched but pretty much mirrors everything it's only on one year more than the stats for last year so there's no surprise there and I compared the stats from last year that's why I started with a bit of the video instead of the head of this new presentation and about pretty much every stats here is the same except the maximum duration there was a new issue I didn't have time to look up what was the issue but if not if I think someone here knows because of the rafter but something was open for a while and then was closed and this is the issues open per day we don't have the red lines for the Israelis the tool that generates this takes a while to run on this laptop and the data collection takes days but the tool to run only the ipython notebooks about 30 minutes on this laptop so I couldn't update it with the red lines for the new releases but they're about there and yeah about there so strangely there's a bump for new inches open before between the two releases but nothing really remarkable for the releases and if we look back here for the ratios open by day there's this bike that was pointed out last year that's the next wiki move which was closed around there skewing the graphs [Music] this is pretty much the same that the others sadly I had trouble getting the data for the pull requests in the same format what used in the last year so I don't have those stats this is why it's only the issues that I'll be looking maybe into generating those later then put them online but sorry about that and I'm going to talk about the next subject yeah we can yeah maybe on the graph we still are opening more issues than we are closing all the time like we are above the zero forever so that's it's about the same for the pull request though yeah so that's well might be considered a problem but yeah well I think it's I personally think it's pretty common in large larger distributions to have lots of unsolved issues that somehow aren't that much important for people to spend lots of time on all right so that were some statistics now maybe well I'll say something about the releases themselves well in the unlikely case that you didn't know we have a well the main development process
is a kind of rolling style compared to some other distributions and that's not really suitable for everyone so every half a year now we are doing stabler releases which are supposed not to break things match either by just real box or just by the fact that the that something changes that you don't expect not really being bad for anything so right now the the cycle has stabilized on every half a year we fork off the master branch we we test we have some period where we don't do any large changes to it for one month and then that when it looks good it gets like officially blessed as suitable for usage and and that gets maintained for for the half a year right so for that I'll quickly say what kind of changes are expected to get into this releases it it's the the main focus of these releases were for like like for production environments for example and similar ones where you mainly need security fixes so that's the main thing to put these back ports in there and many upstream packages provide some kind of stability updates stable updates so so for example Linux kernel so these are also the main things that can get in there though maybe not as important as the security fixes yeah well and well for some software like browsers it's basically every release is security released so that's that's always put in there typically so there might be some confusion about who actually does the things so right now the workflow was that that people who do the changes to the main branches are or the people who merge them are expected to usually notice that these kind of changes for example fix security bugs or something like that and we would like them to either notify us but the best to create backporting pull request or backport the changes directly anybody can do a back port you don't need to be a committer everyone can do one back port so if you open a PR you don't have commit bits it's not important you know that this PR is going to be back ported since it's either a we had this that showed up quickly these are their current the current rough guidelines for back porting and they are linked in RFC does currently work in progress we're going to touch about it RFC and later on but those if anything matches this it's a candidate for a back part forget about that that's not right anymore there's a darwin stable branch now but it's mostly the security sensitive stuff that's those are important even if it's a breaking update for that software like Chrome if if Chrome gets updated you okay we riding the you don't back port
okay don't look at the don't look behind the curtain so the security stuff like the chromium chrome that's extremely important since that's a big security
sorry a big surface of attack and there's sorry I'm going to need to rate to be about say there is a bug fixes in applications sometimes they some software gets updated by the other distros like debian fedora for their stable branches that's a good place to check for for patches that fixes the issues that major updates would have fixed but we can't really back port filling that if the software is not if it's like a leaf from the dependences dependency tree sometimes it's right to update with major versions especially for services for things that depends on services like Spotify if the service changes we can't just tell you our users well what if I changed we can't that's not a good UX so software that depends on other services like those cryptocurrencies there's a the well Spotify is the prime example now back to who ah right so yeah well there's the the RFC in progress so right now it's everyone because there's really the speed of inflow of pull requests and and or changes directly to master is really huge so that couldn't even two people couldn't really manage to watch all of those changes and decide whether they are suitable right while for the like in in several months there will be another cycle release cycle beginning and we don't really know who will the next release manager be well like the the approach now is that the there are always two managers at once being replaced in even out fashion right so I will be living for the next next one and we are about to choose my replacement and so so you can think about this whether you would like to do organize it and if you are interesting write us an email and even if you think you can't do it for any reason even if you have any interest ask us we will be able to talk maybe you can do it probably you can do it I thought I couldn't do it I did do it and everything went fine since it's like said senior junior I was out along the way by mostly Vladimir but also the other previous realize managers the community was I don't have a list of names since I would pretty much least half of the committers since well active committers since everything everyone was I there's nothing to say how about that so even if you think you can do it contact us and we're not only looking for 18:03 since well normally we will we should have add a release manager at the end of 80 note or at the end of 1803 the release manager should have already been selected it was said I was asked in August so already there was a bit of a gap and we I don't want this to happen again so show yourself for 1903 and if you have questions or maybe you think 19:03 you can do it but you know you have the time for 1910 also show yourself so we know who's interested well I don't think we have anything else there do you have any questions well maybe we need [Applause] so not a question but an amendment if you merge super requests on github and you don't know whether you should pack pot but what I usually do is also as just ask the user that brought up the back part because they know the software usually they have a motivation where the Mitsos up great and they also might know if it affects your current stable branch because not all updates or all fixes are also relevant for the back port case that wasn't a question but that's nice do you have an instruction so I often up until now at least back for either new packages or updates under new attributes is that okay or I just like it because it means I don't have to change everything I can just change that I know I could use overlays and maybe I should but I'm just what's your thoughts on should we do it at on new packages or what or a major update offender a new attribute under a new tribute yes right now we don't have any better back board guidelines than what was written there but the idea is from stable to stable you shouldn't have to change anything so if you use a new attribute to backport something that new attribute has to be in this table but is that right I'm I don't know I guess that's my question as release manager do you want us to be doing that or not well I think these
kind of changes are very unlikely to break anyone's system so that does seem alright so yeah it's a it's a bit the rules are overall bit hazy just we are
creating them as we go it's okay do we have another questions and where from anyone nope okay then once again thank you guys for your talk I was I was checking the I was checking
the time hey we're wondering what's up next and I'm happy to say that what's up next is you feeling your body with coffee because we've got a 30-minute break so
Feedback