NixOS 18.09 release managers
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.
Čunát, Vladimír
Dionne-Riel, Samuel
The release managers talking about the latest NixOS release
 Okay, hello. So here's Samuel, the new release manager now. Right, so here'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 Nixcon. But yeah, although they haven't really changed that much since there. Well, you can see, like, well, like on the whole the activity is continually rising. And 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 growing. And compared to last year, last year's 2017, was about there, the point, I don't know the software, sorry, the point was about there when the presentation was made. So if we compare, we're 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 open 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 surprise, since it's not the issues open since last year, since forever. So the core temp and PTI will need to work a bit more if you want to be on the top three. But pretty much every other names just switch around in there. And the same happened for the number of issues by Assigny. The top two, I believe, was the same. The last one, LNL7, was the same. But in the middle, there were some changes, some places switched, but pretty much mirrors everything. It's only 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 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 laughter. 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 these relays. 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 DIPython 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 issues open between the two releases, but nothing really remarkable for the releases. And if we look back here for the issues open per day, there's this spike that was pointed out last year. That's the next weeky move, which was closed around there skewing the graphs. And this is pretty much the same data than the others. And sadly, I had trouble getting the data for the pull requests in the same format that was used in the last year, so I don't have those stats. This is why it's only the issue stats. I'll be looking maybe into generating those later and put them online, but sorry about that. And I'm going to let Vladimir talk about the next subject. 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. It's about the same for the pull request though. So that might be considered a problem, but yeah, well, I think it's, I personally think it's pretty common in 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, the unlikely case that you didn't know, we have, 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 stable releases, which are supposed not to break things much, either by just real bugs or just by the fact that something changes that you don't expect. Not really being bad for anything. Right now, the cycle has stabilized on every half a year. We fork off the master branch. We test, we have some period where we don't do any larger changes to it for one month. And then that when it looks good, it gets like officially blessed as suitable for usage. And that gets maintained for the half a year. Right. For that, I'll quickly say what kind of changes are expected to get into these releases. It's the main focus of these releases were 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 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, for some software like browsers, basically every release is a security release. 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 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 a back porting pull request or back port 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 the current rough guidelines for back porting. They are linked in RFC that's currently working progress. We're going to touch about it RFC later on. But if anything matches this, it's a candidate for a back port. 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 Chrome gets updated, you, okay, we're hiding the back ports. 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 read to be able to see. There's bug fixes and applications. Sometimes the, some software gets updated by the other, this throws like the Bienn, Fedora, for their stable branches. That's a good place to check 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 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 our users, well, Spotify changed, we can't. That's not a good UX. So software that depends on other services like those cryptocurrencies, there's the, well, Spotify is the prime example. Back to the hook. Right. So yeah, well, there's the RFC in progress. So right now it's everyone because there's really the speed of inflow of pull requests 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. And right, well, for the, like 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 approach now is that there are always two managers at once being replaced in even old fashion, right? So I will be leaving for the next one and we are about to choose my replacement. So you can think about this, whether you would like to organize it and if you are interested to write us an email. And even if you think you can't do it for any reason, even if you have any interest, we'll 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 or junior, I was helped along the way by mostly Vladimir but also the other previous release managers. The community was, I don't have a list of names since I would pretty much list half of the committers since, well, active committers, since everyone was helpful, there's nothing to say about that. So even if you think you can't do it, contact us and we're not only looking for 18.03. Since normally we should have had a release manager at the end of 18.03, the release manager should have already been selected. It was, 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 19.03 and if you have questions or maybe you think 19.03 you can't do it but you know you have the time for 19.10 also show yourself so we know who's interested. Well, I don't think we have anything else. Do you have any questions? Well, maybe we need. So not a question but an amendment. If you merge pull requests on GitHub and you don't know whether you should backport, what I usually do is also just ask the user that brought up the backport because they know the software usually they have a motivation why they made this upgrade and they also might know if it affects the current stable branch because not all updates or all fixes are also relevant for the backport case. That wasn't a question but that's nice. Do you have an extra question? So I often up until now at least backport 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 that? On new packages or what's the other? Or a major update but under a new attribute. Under a new tribute. Yes. Right now we don't have any better backport 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 don't know. I guess that's my question. As release manager do you want us to be doing that or not? I think we can work around it with overlays or we can add it to... Well I think these kind of changes are very unlikely to break anyone's system so that does seem alright. Keep doing it then. So yeah it's a bit... The rules are overall a bit hazy just we are creating them as we go. Do we have another question somewhere from anyone? Nope. Okay. Then once again thank you guys for your talk. I was checking the time table wondering what's up next and I'm happy to say that what's up next is you filling your buddy with coffee because we've got a 30 minute break. Okay.
 Okay, hello.  So here's Samuel, the new release manager now.  Right, so here'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 Nixcon.  But yeah, although they haven't really changed that much since there.  Well, you can see, like, well, like on the whole the activity is continually rising.  And 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 growing.  And compared to last year, last year's 2017, was about there, the point, I don't know the  software, sorry, the point was about there when the presentation was made.  So if we compare, we're 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 open 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 surprise, since it's not the issues open since last year,  since forever.  So the core temp and PTI will need to work a bit more if you want to be on the top three.  But pretty much every other names just switch around in there.  And the same happened for the number of issues by Assigny.  The top two, I believe, was the same.  The last one, LNL7, was the same.  But in the middle, there were some changes, some places switched, but pretty much mirrors  everything.  It's only 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 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 laughter.  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 these relays.  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 DIPython 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 issues open between the two releases, but nothing  really remarkable for the releases.  And if we look back here for the issues open per day, there's this spike that was pointed  out last year.  That's the next weeky move, which was closed around there skewing the graphs.  And this is pretty much the same data than the others.  And sadly, I had trouble getting the data for the pull requests in the same format that  was used in the last year, so I don't have those stats.  This is why it's only the issue stats.  I'll be looking maybe into generating those later and put them online, but sorry about  that.  And I'm going to let Vladimir talk about the next subject.  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.  It's about the same for the pull request though.  So that might be considered a problem, but yeah, well, I think it's, I personally think  it's pretty common in 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, the unlikely case that you didn't know, we have, 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 stable releases, which are supposed not to break things  much, either by just real bugs or just by the fact that something changes that you don't  expect.  Not really being bad for anything.  Right now, the cycle has stabilized on every half a year.  We fork off the master branch.  We test, we have some period where we don't do any larger changes to it for one month.  And then that when it looks good, it gets like officially blessed as suitable for usage.  And that gets maintained for the half a year.  Right.  For that, I'll quickly say what kind of changes are expected to get into these releases.  It's the main focus of these releases were 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 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, for some software like browsers, basically every release is a security release.  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 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 a back porting pull request or back port 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 the current rough guidelines for back porting.  They are linked in RFC that's currently working progress.  We're going to touch about it RFC later on.  But if anything matches this, it's a candidate for a back port.  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 Chrome gets updated, you, okay, we're hiding the back ports.  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 read to be able to see.  There's bug fixes and applications.  Sometimes the, some software gets updated by the other, this throws like the Bienn, Fedora,  for their stable branches.  That's a good place to check 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 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 our users, well, Spotify changed, we can't.  That's not a good UX.  So software that depends on other services like those cryptocurrencies, there's the, well,  Spotify is the prime example.  Back to the hook.  Right.  So yeah, well, there's the RFC in progress.  So right now it's everyone because there's really the speed of inflow of pull requests  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.  And right, well, for the, like 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 approach now is that there are always two managers at once being replaced  in even old fashion, right?  So I will be leaving for the next one and we are about to choose my replacement.  So you can think about this, whether you would like to organize it and if you are interested  to write us an email.  And even if you think you can't do it for any reason, even if you have any interest,  we'll 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 or junior, I was helped along the way by mostly Vladimir  but also the other previous release managers.  The community was, I don't have a list of names since I would pretty much list half  of the committers since, well, active committers, since everyone was helpful, there's nothing  to say about that.  So even if you think you can't do it, contact us and we're not only looking for 18.03.  Since normally we should have had a release manager at the end of 18.03, the release  manager should have already been selected.  It was, 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 19.03 and if you have questions or maybe you think  19.03 you can't do it but you know you have the time for 19.10 also show yourself so we  know who's interested.  Well, I don't think we have anything else.  Do you have any questions?  Well, maybe we need.  So not a question but an amendment.  If you merge pull requests on GitHub and you don't know whether you should backport, what  I usually do is also just ask the user that brought up the backport because they know  the software usually they have a motivation why they made this upgrade and they also might  know if it affects the current stable branch because not all updates or all fixes are also  relevant for the backport case.  That wasn't a question but that's nice.  Do you have an extra question?  So I often up until now at least backport 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 that?  On new packages or what's the other?  Or a major update but under a new attribute.  Under a new tribute.  Yes.  Right now we don't have any better backport 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 don't know.  I guess that's my question.  As release manager do you want us to be doing that or not?  I think we can work around it with overlays or we can add it to...  Well I think these kind of changes are very unlikely to break anyone's system so that  does seem alright.  Keep doing it then.  So yeah it's a bit...  The rules are overall a bit hazy just we are creating them as we go.  Do we have another question somewhere from anyone?  Nope.  Okay.  Then once again thank you guys for your talk.  I was checking the time table wondering what's up next and I'm happy to say that what's  up next is you filling your buddy with coffee because we've got a 30 minute break.  Okay.
Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_0_815.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_816_1763.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_1764_2447.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_2448_3047.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_3048_3971.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_3972_4607.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_4608_4883.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_4884_4991.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_4992_6875.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_6876_7163.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_7164_7355.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_7356_7907.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_7908_8087.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_8088_8651.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_8652_9107.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_9108_17603.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_17604_17747.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_17748_17891.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_17892_17939.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_17940_18011.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_18012_18107.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_18108_18155.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_18156_29303.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_29304_29507.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_29508_29699.png Vladimir_Cunat__Samuel_Dionne-Riel_-_NixOS_18_09_release_managers_GoAuPauFkW0_29700_29703.png