Releasing NixOS – History, Hummingbird and Henceforth

Video thumbnail (Frame 0) Video thumbnail (Frame 13642) Video thumbnail (Frame 17607) Video thumbnail (Frame 27417) Video thumbnail (Frame 33147) Video thumbnail (Frame 35098) Video thumbnail (Frame 38661) Video thumbnail (Frame 43322) Video thumbnail (Frame 44905) Video thumbnail (Frame 58382) Video thumbnail (Frame 65224) Video thumbnail (Frame 67591)
Video in TIB AV-Portal: Releasing NixOS – History, Hummingbird and Henceforth

Formal Metadata

Title
Releasing NixOS – History, Hummingbird and Henceforth
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
2017
Language
English
Production Year
2017

Content Metadata

Subject Area
Abstract
As the latest release managers, we will describe how NixOS releases have been done in the past and how we want to encourage the Nix community to participate in the release process. We are going to highlight some interesting new features of past releases and the then brand-new 17.09 'Hummingbird' release. Finally, we present you some ideas for features we would love to see implemented. We will give you an impression of the NixOS release process, how the release team works (RFC15) and your duties as release manager. Not to scare you away but to motivate you to step up as the next release manager. In particular, we will give you an overview of promising features the community has suggested but remain to be implemented. Some of those are general service hardening with systemd, a new test-runner container backend for quicker service tests and the service abstraction layer to use NixOS service modules in Docker containers or swap init systems.
Statistics Service (economics) Wrapper (data mining) Code Multiplication sign Control flow Branch (computer science) Shape (magazine) Semantics (computer science) Software bug 2 (number) Mathematics Roundness (object) Computer configuration Kinematics Software testing Website Compilation album Task (computing) Domain name Overlay-Netz Module (mathematics) Wrapper (data mining) Electronic mailing list Complex number Data management Process (computing) Software repository Chain Software testing Modul <Datentyp> Family Row (database)
Server (computing) Statistics Socket-Schnittstelle Service (economics) Open set Number Web 2.0 Medical imaging Web service Integrated development environment Software testing Abstraction Booting Physical system User interface Installation art Default (computer science) Service (economics) Computer-generated imagery Expression Bit Front and back ends Web application Integrated development environment Normal (geometry) Software testing Right angle Abstraction
Rule of inference Slide rule Statistics Graph (mathematics) Software developer Projective plane Line (geometry) Open set Number Software bug Mathematics Number Mathematics Sign (mathematics) Data management Bit rate Oval Analog-to-digital converter Right angle
Slide rule Polygon mesh Statistics Control flow Maxima and minima Open set Number 19 (number) Wiki Number Cross-correlation Roundness (object) Algebraic closure Analog-to-digital converter
Number Statistics Software developer Multiplication sign Right angle Open set Number 2 (number)
Laptop Default (computer science) Slide rule Statistics Link (knot theory) Slide rule Building Multiplication sign Limit (category theory) Bit rate Web browser Limit (category theory) Statistics Bit rate Repository (publishing) Repository (publishing) Volumenvisualisierung Software testing Volumenvisualisierung Logic gate Backup Resultant
Statistics Link (knot theory) Slide rule Building Multiplication sign Self-organization Volumenvisualisierung Statistics Spectrum (functional analysis)
Point (geometry) Laptop Trail Functional (mathematics) Code Multiplication sign Set (mathematics) Control flow Branch (computer science) Open set Mass Mereology Revision control Mixture model Mathematics Differenz <Mathematik> Tablet computer Spherical cap Different (Kate Ryan album) Repository (publishing) Energy level Software testing Volumenvisualisierung Information security Task (computing) Link (knot theory) Graph (mathematics) Slide rule Building Sound effect Software maintenance Statistics Data management Message passing Process (computing) Module (mathematics) Convex hull Table (information) Writing Booting
Point (geometry) Area Implementation Statistics Link (knot theory) Slide rule Code Bit Multilateration Drop (liquid) Mereology Statistics Flow separation Data management Mathematics Process (computing) Right angle Software testing Volumenvisualisierung Information security
Statistics Link (knot theory) Slide rule Statistics Number
hello ah hi thanks to thank you all for coming it's so great to finally meet all
of you in person so our talk is about releasing next to us and get you motivated to help out in the release process because it's a very hard task and we need more volunteers and in the end we have some statistics that Robin prepared that gonna blow your mind so let's start with the boring stuff one year of Nick's OS so the first release 1703 and this year codename gorilla was released by Robin it had a few cool features which is next packages overlay done by MVP and the set VD wrappers we have around 80 new service modules and of course lots of bug fixes the current release 1709 hummingbird unfortunately we don't have very new exciting features in this release but we had a lots of cleanups and lots of updates but you can read within the release notes so like PostgreSQL stuff and my stuff moving around that you have to manually and around 70 new service modules so if the our last releases now to release managers a few months ago we started an RFC if you haven't seen it there's an hour of C's repo that it's about simbad started awesome where we can like shape the community and to processes around next to us and the next ecosystem we have quite an RFC for release managers because we have to get problem that we had like four years only one release manager domain so he couldn't really do it anymore because it was so much work and he asked Robin to do it but it wasn't a very sustainable process to do so we proposed that there are now two people involved in the release process one alt release manager and one release manager so one coming from the previous release and one new release manager that is appointed by the two released managers before him so this is the new process that also was approved and we'd like to continue with that we hope that we can in that by spread the knowledge how to release next to us there's even some documentation that we continuously try to update and yeah it should right now be documented enough so you can so you know what you're actually doing so what are the duties of a risk manager the important thing is to pick goals and issues to fix in the next release this is very difficult because we have lots of issues we have lots of bugs and it's very difficult to prioritize them also in each release we have some blockers like issues we have to fix before the release actually for this release we had some really weird blockers like QE more interface renaming stuff that's due to a kinetic option chains and it was very difficult to to decide on the right solution like right now we decided to put it in the release notes and make you aware of it but we could also have done some automatic fixing but that would be a would have been a little bit weird because some semantics would have changed so this is actually more difficult than it looks the other thing is there are lots of PRS and new features hanging around that are not merged yet so you have to like not the people to like get their stuff ready and also review it that's a very difficult task like for this release we planned like to have the cross compilation feature and and John Erickson actually worked very hard on this but in the end we weren't able to deliver it unfortunately but for the next release the other thing is to write the release notes so we you have to go through all the commits all the history happening since the last release to find out what has changed to find out what our breaking changes that you have to document for the users also updating the website but that's actually easy and what's the most annoying task is to watch hydra for failing bills and ten eunichs OS tests we have some weird failures in EXO s test some transient backs and Huey mo probably related to Io I'm not sure but a lot of times Nick's OS tests fail and when you restart them they won't fail so one of the main tasks I was doing to watch Hydra hit refresh oh it's failed again we started yeah great so somebody should eventually fix that but I don't feel qualified the other thing is like after the branch of end after the release you have to monitor a master for bug fixes coming in and back put them to the release branch it's also very time-consuming because there are a lot of code coming in lot of code missing data and of course this is the the most interesting and most fun task you can pick the codename for the next release so not the release that you are releasing but the next release because after the branch of the codename has to be set in the new in the next packages master so actually the second release you're releasing you get to choose the codename yeah when you are the newbies manager yeah so that's a fun task okay so what we release managers the first release was 1310 if I read correctly and must whisper echo the one after that too and then domain that has released run for releases in a row let's give him a round of applause also echo echo of course I look at their release male so shall he be yeah okay okay and then the 1709 we started with to release miniatures of the new RFC so the next release 18:03 will be called Impala the fun thing about Impala it's some kind of antelope which is in the same family as news so that's why we picked it and we have a new list manager it's Vladimir Cunha yeah you might have seen on github might have seen on github it's always fixing stuff always doing lots of commits really awesome that we happen that you know is the official next service manager okay and let's look at the future nexus 18:09 need service manager if you're up for the job please come talk to us when we release a channel free we have to pick a new list manager and it might be you so please do it we don't want to do it after that because it's really much work and so stressful but but but but it is nice work you that it's yeah it sounds much worse than it is actually I told
you what you have to do so you can decide okay now we have some future
ideas for features that we would like to have because hey we want to take over the world right we have to fight the like the Tucker issue somehow so I my idea would be to like be the standard tool for building docker images so what we would like so we would very much like to have a service abstraction layer comp him also did some work on that but I would very much like to see it in 1803 the other thing what would be cool is a container beckoned for next OS tests because yeah a bit biased because I have restarted so much nicolas tests but like some tests could be run in in a container instead of a KBM environment because when you only test a non normal service it can just be run in a container when you are testing like the Installer and the bootloader it has to be done in a VM of course the other thing is the system is not as hardening system is lots of hardening features we should enable by default the other thing is Nick's or Nick's OS user environments as a pull request open for like three years you should get that ready yeah too much trouble yeah let's talk about that the other thing is web service abstraction so we have like lots of web services opening ports opening like fast cgi sockets or SETI sockets or whatever and we would like to abstract over that and like glue together a web server and a web app more easily or our virtual host in a web server and a web app more easily so you don't have to like remember paths or express if ik specified paths or port numbers and we would like to have a new PR testing but Graham is working on that and I hope we will have that soon ready maybe after a hackathon ok and now to the interesting stuff globin has made some statistics well yeah I've collected some statistics
on commits issues and put requests I
have a lot of data and though I use a quote of
probably for the slides now I know just go ahead and start with the most obvious stuff commits per year you can see
around 2014 2015 and 2016 we've had more than 15,000 commits last year was about 17,000 this year we'll probably reach about the same and that the interesting stuff in there is the percentage of change compared to the year before we can see in 2012 we had a really high rate of change again does anyone know what happened in that year like don't know that that was the year when next packages development moved to github and a lot of new contributors started contributing can also see that here that's the number of committers which was growing really enormous lis last year we had around 800 this year already I think nearly 900 and we still have a few months left so that will grow even more and again in 2012 there was a really really big change that's not a quite nice statistic you can see around lo 2008 to 2011 there were not that many people but doing a lot of work and you can see how due to there being much more like drive-by contributors the rate of commits per committer has been less but that's only that's actually a good sign the people can contribute quite easily that's the number of commits per day like normally is around 40 to 70 commits a day which is quite a lot and what you can actually see quite good if you zoom in the red lines are the releases and like around at least the last three releases people suddenly remembered they should commit and submit their stuff which is actually quite yea big it's not that nice for the release managers because there's a lot of change right before the release that's the same graph as the one before number of commits per day that happens too we see the pull requests to later actually it's a lot of people remembering that they should actually get their stuff merged yes probably yes / yeah I'd like to encourage you to like commit your stuff in between two so so that it makes it easier to release the stuff then two issues that's yeah that we can see the github history started in 2012 we have had two alone in 2016 2500 issues were created that is a hell of a lot and that actually I'm not sure if many other github projects have like those numbers we're probably one of the github projects using the issue tracker most yeah there again please like people like not not even being able to commit we'd like to encourage you to like go through issues triage them and have a look because we have quite a lot of open issues to we're probably a lot of them really issues anymore but they're just so many the we have difficulties to cope with all of them here numbers of issues opened by different users just I say nothing then numbers of issues by assignee might be a reason for the next release manager [Laughter] I'm appears to be careful too
here's some statistics about how long it takes to fix issues or to close the issues actually doesn't have to be fixing them as you can see with 8 second issue which is quite nice probably someone I think he closed it himself but but we can actually see like 50% of the the issues are closed in 7 days which is not bad actually a fun fact the maximum the 1700 days was an issue created by Elko in 2012 that the MySQL closure size was too big and was closed I think half a year ago now and yes some the comments - like the maximum 156 comments on one issue that's quite a lot yeah that's the same statistic as the one we had with the commits four issues open per day we can actually see a large peak in there that was when the last wiki was shut down there was a the issues to move the wiki and what we can actually see is that we don't have that much correlation with releases in the issues which is quite nice because the like tells us the release the releases didn't break too much that's the issue is closed per day we like January generally closed five issues a day that is quite a high number two and actually like for 1703 we can actually probably see the a lot of people noticed so I've broken some stuff and fix it a month before the release that's issues open versus closed per day yeah we can actually see that we hardly ever go below zero which means we're actually like collecting issues every day we should try and fix that now pull requests can say last year we had seven thousand pull requests this year too I think that is the data from round five days ago so we actually might have might have as many pull requests opened as in 2016 now already here we have number of pull requests per user the Christmas is leading that statistic and yeah I
actually wanted to change that to numbers of PA p ours by merger but I think I forgot that one I'll I know that one is that I wanted to drop the other slide actually yeah we can see Mick 92 is in front of probably everyone will have noticed because it's an insane number of prayer requests he's merging you are him with Python stuff and the rest and then Tommen isn't that far back to and Jagger Jagger yeah but yes certainly he is he should do more again it was awesome yeah obviously please yeah here actually again some
data on the comments and review comments and the merge duration actually that is merging unclosing what is it no I think I think that is really only pull requests that are merged I don't know who managed to do that in two seconds I have to look which one that was that looks interesting but yeah 75% of the pull requests emerged in two and a half days which is really nice [Applause] then the last few statistics I'm not sure yeah but yeah numbers of pull requests created per day that's what I said earlier to that it's not only like pull requests being merged right before the release but also pull requests being created right before the release and it's like 30 a day yeah I think I have yeah pull requests open versus merged you can see that the last two months were actually like the worst we had since development merged a move to get up there like around two and a half pull requests being opened and not merged a day currently so please review stuff help the people merging so that we can get more stuff merged I think we're around 550 open pull requests now and I can remember times where we were keeping it below 200 250 that is has grown
insanely in the last few months yeah that was the data I had or the data I
managed to look through the statistics and slides on github with git LFS and github actually rate limits you quite hard that's why it might not be possible to clone all the data from github that's why mirror mirror on our gate lab so if github doesn't work please just use the gate lab I'm currently building the whole statistics and the slides on our Hydra the slides sadly don't render properly directly on Hydra but if you just Nick story alloys and run the browser from the result you'll be fine and we definitely need more statistics if you have any ideas for more statistics just open an issue or implement it yourself everything is that the slides you saw are just Jupiter notebooks render the slides there is a whole more of data you can look through it's all in the repository and was generated with get pandas and Python get up back up but actually with some touching and hacking around so I'll I've opened pull requests for get pandas but apparently broke some tests I didn't manage to fix yet and the Python get a backup actually doesn't give you that much data regarding for example who merge the pull request by default and he hacked around in there and didn't have the time to submit all that upstream and I'll do that in the next few days and probably add or I'll definitely add the how to gather the data to the readme then yep that's all I have to say so order any questions
no questions everyone asleep yeah so
this is your of the statistic only in the neck spectral Reaper or all the Reapers in the next organization that was only next packages I didn't have
enough time to do more yeah that will get us yeah yeah that that is stuff like you could pull requests and welcome issues that that is like the interesting stuff we need any ideas for more statistics probably quite simple just to
graph the backlog of open issues and how useful are the tags that we put on the issues and pull requests for releases it depends so we only watching a few labels like the blocker label is very important for us also the mass rebuild label and the security level for the most part like the package update label or package new label is mostly useless unfortunately we should reorganize them at some point but I don't have really good ideas right now but yeah yeah that's a microphone I was told as managers in antennas can you say what what were you on the table feature squash emerge basically when I do pull requests I do some fixes like maintainer request fixes from me and then I myself I'd I don't see the point when maintainer writes to me please squash mm-hmm time passes I see the message oh I am NOT on the same laptop our function and I need to I squash it and commit it back and manager then sees it and then maybe he requests some other changes but when maintainer can he looks at the code maintainer understands what it does he squashes I think depends on the poor request if it's like only small package updates it normally is fine to just use the squash and marriage button but we often have like pull requests updating the package and the module and those are like two logical commits I don't want to have squashed what I sometimes do is simply push on the like pull requesters branch and squashed things myself and then merge normally but yeah normally it should be fine to just use quash emerge but sometimes you want to keep commit separate or simple simple requests yeah yeah so what's the as a release maintainer what's the single biggest task which is taking up relatively much time it's a mixture of monitoring Hydra and watching master like we we actually had a branch which was like tracking master where we always pushed the commit to that branch of the Committee of Master to that branch up to the point we had reviewed to like keep track where we stopped reviewing the last time last time I didn't do that but there there was me alone watching master and I think we had a few less commits that release compared to this one and this one was like maybe half an hour a day going through commits so watching master is hot because like you have to if the branch of already happened you have to back what the commits and like tested of course and and in the first two weeks it's easy but it's becoming more and more difficult the more time goes on so right now you get the first conflict so mmm-hmm left effect but even more that's okay and actually in not the thing we do a lot is like pinging people on different issues like every hostile issue pity gets pinged for example because we know he knows what's wrong and we know he'll fix it definitely the pull request testing would help a lot because we'd then don't like have to run Knox review for every pull request we want to merge or yeah like what would be nice if we could like cap job sets for and I don't know a bunch of fifteen pull requests merge together and just like test all of the rebuilds that were would cause because there are quite a lot of pull requests like only changing 20 30 40 bills and like rebasing them on top of each other and creating a job sir automatically for that would probably make it a lot easier also I'm from time to time not sure if getup is really the right tool for us but don't get me wrong github is great but it's not easily customizable because it's close to us yeah but we we've profited a lot from github of course we've got a lot of new commits us from github so I'm not sure that will better go from here yeah well more of a note for the back porting of two stable branches I I would prefer not just because I think already when people create pull requests or merge them they should think whether that change is suitable for backporting and I would like them to do the work because they update the package often they are maintained errs and they know more about it yeah then the release manager who well can just know everything all the packages so so I would prefer to ship that to those due to maintenance of the packages and them totally yeah and another thing there's people we'd like to encourage all of you to actually write release notes yeah because I spent like two days going through the whole nexus folder diff trying to figure out the breaking changes in there which I think worked out quite well but I don't think we should do that like that but really be more strict on letting people add release notes yeah also the package managers really should do their job because I had a few commits for this release and after that release they were actually fixing security issues but they are not tagged as such and were not backported so the one who merges the pull request has to beg for it if it's relevant for firstable because like as if said tracking master
is hard reading all the commits is really hard it's a very time-consuming
job oh so everyone could help out well can much or at least ping gram France Tom and Rob me people people who reppin us yeah yeah people who regularly back port stuff if it's I don't know too much work or too complicated or I don't know but at least ping us because we'll happily do security backporting obviously and that is really important that we notice security issues because going through all the change locks of minor package bounces I don't like it well I think Graham will say a bit more yeah on that later yep right so first of well you did a marvelous job at making the drop of release manager like a really intriguing aspect and I'm like thrilled to do that maybe not managers team that would be like way less scary because yeah I mean to me it seems like a scary aspect and in the end of course one person has to be bold enough to say BAM let's merge but yeah I mean that that is actually what we started to do with our FC we now always have to release managers for release and the cool thing about this we have previous release managers who know who are they have done it and always can jump in and help out yeah so like 1703 Domon helped me a lot with releasing it it's a bit unfair to say that i was the release manager of 1703 and then the two of us for 1709 because domin actually like did quite a lot for 1703 too and I would like to get your thoughts on that is like this this shade of of how many people get merged X's only one hand you can say it's a bottleneck right on the other hand if you I mean we've seen the spikes anyway it but on the other hand it's like if we give more if you give more access to too many people then maybe too much stuff it's getting rich maybe already stuff is getting much better sometimes wonder like that at this point so I wonder what you think about the trade-offs that like how many people can merge how many should enrich should there be some extra tooling to limit these things of merging and the parts that can be merged by dividuals and and stuff like that so my opinion on that eventually I would like that know that nobody has push access to master anymore everything has to go so I've pushed a master a lot and a lot of you have fixed after me so thank you but the thing is pushing to master is nice to get stuff out really quickly but we have to have Reb you and we should have more people being able to merge of course but committing directly to master is dangerous as we've seen in the past so I think we should adopt it at some point but first we have to get the tooling right yeah it has to be more reliable than Travis CI that I mean gram has done some work on the giving Dartmouth walk yeah Domon and I started building stuff to make testing pull requests on hydro possible but I haven't finished that and I'll definitely have a chat with Graham on how to improve all merged our ideas and implementations and try and get that started as soon as possible but yeah I was delayed by being a release manager and didn't get as much code out as I
wanted and now like gathering the statistics took me the last two or three weeks but yeah that is definitely something we will and have to improve on and we're back porting so should people that are creating poll requested they create a separate poll requests for the same issue to backport the issue to make it easier for you guys or what would be the best way to handle that if you don't have commit access to cherry-pick it it that would be great but if you open a pull request you should also test it and that's the difficult one because like when you ask me to pack but it of course I will pack but it but and I'm not sure when I will get to it because I have to test have to check if everything still works and that's difficult but there are some improvements in that area because I think like practice working on next packages tests and there's some more stuff of the nexus test going on so yeah we have to improve on that too and also when we have automated testing this will also go away so right now you can open pour requests but please ping at least some of the release managers about it but yeah back parting is also like cherry picking is also possible and try to get the cherry pick right cherry pick
- X all right last question you were speaking about stats do we have stats about the number of commits which were made without a poll request sorry we asked that about the number of commits made without it all requests oh no we don't have currently but that is something we should do all right shouldn't be too hard I think [Applause]
Feedback