 All right, good morning, everyone. I think we're getting ready to start now I am Niels I'll him to talk about stretch and moving forward Today, I'll talk about the just release Which we already did. I'll be talking about some important dates for the stretch release and Then some of the changes we hope to implement before the stretch release That would be some process changes some new ideas and other crazy things and Then it goes without mention. There's a GCC transition, which I will briefly end up talking a bit about so The Jesse release So the good things are a couple things that work really well for us. All to remove was again being one of them Among other things we also very happy that many of you provided sensible patches that were ready to go into Jesse as this will be very few remarks and Did you were very careful with what you proposed? exit and Certainly the freeze was Mostly better and shorter than what we had for we see which is definitely a great plus There are also a couple of items we can improve on the other hand Pre-approvals we get way too many of those and they are extra work for us We still get a lot of uploads with unrelated changes, which costs us to spend extra time reviewing them Extra time talking to people saying we can't have that change you please perverted and We're still not happy with the freeze length, which I guess goes for most of you as well The pre-approvals is somewhat a double-edged sword for us on one hand We're happy that you're careful being extra careful On the other hand, it's an extra round trip for us So when you upload a pre-approval or when you do a pre-approval you say can I upload this? We say yes, we've viewed once then you upload we end up reviewing it again Then improve it so when you go Lots of those you end up doing a lot of extra work for a lot of true will changes so For people that are sensible This is actually harmful us for us to get too many pre-approvals on the other hand if you're not sensible We want the pre-approvals rather than blind uploads We're still looking for ways of improving this workflow so we can avoid either the extra round trip or somehow make people more confident in simple changes simple changes and Without getting too many non-sensible changes We will one of the things we aren't working on is rewriting the freeze policy for stretch So become more clear what is okay, and what is not that's what we hope at least But we will not ever end up with an exhaustive list of this is definitely okay We might have that list of this is definitely not okay, but it will never be exhaustive we're moving on to unrelated changes now and This is some of the things we hear per faced So like it's a leaf package. It cannot possibly break other things It can it has happened and it will happen again or it ends up breaking itself in which case It's not really helpful for us either We also see people uploading a new upstream lease or something with a lot of x changes And we say this is not really working for us And I say but if I have to pair it cherry-pig it or revert it will be a lot of extra work for me You should totally just ignore this thing It just doesn't work for us either. It's pushing work on to us Which we'll come back to in a moment is somewhat of a problem and There's also the part where the changes are I've relevant harmless and shouldn't make a difference There's that truth is sometimes they do And when they do we discover them later than we want to So that's why we insist on reviewing everything And it's extra work. Yes And When we ask people to revert things undo things or cherry-pick things to a reupload with less They you should not wear incline to do it. I understand it's extra work for you as well, but We need that we need to be able to make reverse cheaper to make it be less work So it works for you and for us Also again, please don't upload new upstream releases without a pre-approval Which goes back to the part of try not to do many so many things that need pre-approval because they are a lot of work for us and Yes, we don't like to say no It is often easier for us to say yes to something that needs to say no Because saying no means you have to argue two or three males before people get no is no or First in purple unicorn, I think it's called now So if you want to help and we would like you to help please cherry-pick changes and for some unavoidable craft like When we have these auto regenerative files We have translations please use filter diff send us a filter diff one and tell us what you feel the diff and how We will still see the unfiltered content when we check the package But at least the first screening which this one you want will go faster So on this thing with moving pushing more work on to us The problem is you're saving time by putting more work on us means that if you're not people do that the entire project will end up overloading us So all the other changes will get stuck behind yours and It's just it's harmful for the release process really You want things faster make this work for us Say freeze too long We are looking into doing RC releases somehow Doing pre releases after the freeze before we are ready to do a full release Which means we can do more testing hopefully as well And also might give us better benchmarks of how well the release is actually going Besides looking just at RC box, which is of course a useful metric, but not the only one We will also do some changes to the freeze and as mentioned before the freeze policy I'll get back to the freeze in a moment with the dates There's one thing else we can do I Like you to consider the following little question What happens if two percent of all packages and are not quite ready when the freeze happens? Any takers? No, you read it Yeah, so he said something about deferring it to the first point release if I understood correctly Anyway, my answer is the project will file at least 500 unblocked requests That is 2% of the entire archive right now looking at source packages And that is a minimum number Sometimes we need multiple uploads to get things right d-package system D among others Apped as well had numerous uploads during just a phrase It is actually a very best case. We only see 500 unblocked requests in this case And then the question is will this burn out the release team? Yes It will Will this make the freeze longer? Yes, it will So again have things ready When We freeze and that's the part where I need you to help us The release team cannot have everything ready because there's simply too many packages for Five to ten people to actually get ready at the same time We need you to help us here And that even means fixing packages you don't maintain this is a very helpful thing because We can't really help you when you get two months in the freeze and say why did you remove this package which I Really need but was I'll see buggy for three months And I didn't bother fixing We can't help you then fix it before Then we can help you Now onto something a little more exciting the future We will be talking a bit about the important dates for stretch Now you should do cool stuff for stretch This is the current timeline It's for me now. There'll be a transition. I'll talk about later Which you should keep in mind, but after that go ahead and do cool stuff Then in a year from now That'll be in the summer 2016 You should remember this is this thing called the freeze coming up and you should have your things ready for that That's when you start We move on to the transition fee freeze during the 5th of september, which is About half to a month after dept. 16. Don't remember the exact dates, but Couple weeks after that After the transition freeze We will have two months Where we will not accept any new transitions, but we will have the soft freeze at the 5th of November, which you might remember And of course there is the 5th of december where we will start the actual full phrase I'll come into the difference between these three freezes in a moment And as you will know you have a year to go bananas to some extent and develop new stuff The transition freeze means we will not be doing transitions anymore We hope to be finished with all the transitions by then, but more likely we will This will be the cutoff point for accepting new transitions We would also like to Request people to stop doing fails to build from source testing against testing at this point So we can read out a lot of the fails to build from source problems then The soft freeze Which was the 5th of November. This is the cutoff point for new packages After this package after this date, we will not accept new packages into testing This is regardless of whether or not they have previously been in testing or not So if they're removed they're now staying out And requires manual intervention to get them back in So this is the point where auto removals no longer migrate back automatically when you fix it After being auto removed And finally the freeze is as you mostly know it All changes to testing require manual review And then there will be some changes to the freeze policy We haven't quite finished wording them out, so I will not include them There will be an announcement later closer to the phrase with how below And that's pretty much it from the changes to the phrase Any questions to this part? Nope, doesn't look like it. All right, moving on Some of the changes we will do So one of the things we have noticed during Regular development cycles is that we suffer from a kind of a problem You will have some packages in testing that has a new version in unstable. It's in itself. It's not a problem The problem is sometimes the version unstable has been a different version for a very long time Like a new upstream release The issue here is the package getting out of sync Developers are working against the unstable version. So that's what they're all working for But if this does not progress into testing, this will not actually be the package we're releasing So we're doing a lot of work on a package that may or may not actually end up in the release There's a backlog here that gets stuck Important changes might get blocked by it because they end up building against the new version And therefore need to wait for the version to be ready, but the new version is not getting ready for some reason So this will block migrations. This will have people work on On the new version. We might discover a security issue in the testing version Which we have no claim way of updating without doing a out-of-band testing proposed updates sort of thing And that's that's a modern issue for us It also happens that we are starting in transition and then notice oops We got a pile of the transition stock behind this Issue in unstable that nobody noticed for two months So The race team looked at this and said well Our point of view the primary focus for testing is to create stable And the primary purpose for unstable is to create testing With that in mind We're considering to remove packages from testing that have been out of sync But unstable for a long time Namely three months This will happen even If they have no issues in unstable in testing, sorry, they obviously have issues in unstable if they're stuck in unstable um The solution for the package container is to fix the problem in unstable and failing that reverting to the version in testing um If there are no other options There are of course some exceptions We will not be removing deep package from testing that would be counterproductive will not remove other key packages And we will be disabling this during phrasers or other long Periods where you are not in control of migrations to testing such as the gcc transition now So that's the general idea Of course once your package removed it can still go back automatically as soon as Whatever blocked it fixed is fixed So in generally if it's stuck for three months, it's probably needs something manually done from your point um Don't keep in mind There will be the freeze the 5th and November if you're removed and didn't fix it before then Your package will be out um So have it fixed before then and you should be good We also have a couple other ideas um We are very close to having auto package tests be bloggers for migrations. Thanks to atonia and martin um This will be a first step. So at this point they will just block if you have an auto package test that failed it will block the migration We have two years ago a proposal of changing the h delay for packages with auto package tests that will not come yet Um, we will look into that later We're also looking at doing the actual release media for the release ahead of time So at the last release, um We had this thing where we we did the release in two hours. That was all the technical work And then we started building media and that took 12 hours And by the time we were done with that the press team was asleep I was ready to fall asleep And we still had to fix up the press announcement area or anything else So that was not really helpful um By the way, it was not the press team's fault being asleep then We sort of planned to be done earlier and we weren't which was unfortunate So the only here is to do the All the release media ahead of time say a week before have it ready be able to do a final testing of it In due time have a couple days for it and then on the actual d-stay ship it out We already have a freeze of Seven days up till the release where we don't accept any new changes. Anyway, unless things are super horribly broken But we tend to have noticed that by now Then as mentioned earlier, we also want to do release candidates or betas during the phrase To have sort of a steady progress and see where we're going And have better release media We're also looking into improving britney. So some migrations Happen earlier. This is mostly helpful for transitions where you have What is called out-of-date binaries? um That we don't actually wait for them to be removed from unstable, but just ignore them and migrate anyway um so And there's a couple of other things on the drawing board. We didn't quite have ready to announce yet So but these are the things we'll be looking at work Finally i'm moving on to the gcc transition As you probably noticed there is such a thing as a gcc transition, which is quite huge um it will take a while and If you have a library affected by it, please do your part If you don't have a library or you have a library, but don't know what to do We have people in immune things. So please be patient and helpful in that regard um and please do not cause interference that might make it longer There are a lot of packages that are not affected by it namely di for example It's mostly unaffected by it at least in migration sense So there are a lot of packages that can be uploaded. Um, but if you're not Please choose experimental We would also like to thank matias close close for his artwork and coordination assistance It would have been a lot more painful without him. So I'd like to give you a hand for matias And this is actually where we come to an end So now you should go forth and fix bugs in jessie. We do accept important and lc bug fixes still for that And there's actually coming a point. We soon be doing a point release. Hopefully we are looking at the next date for that Um, there's a procedure in the dev reference 551. Please read that for how to do it if you're done We're also very happy if people will make more qa tools Especially things where you consider doing automatic enforcements like we have lynch and auto rejects. We will be having auto package tests soon So that would be very helpful Um, if you in your next qa tool your next super qa tool Consider this part where we should integrate it into the archive somehow Also go forth and reproduce. I mean make reproducible built Of the other it's it seems to get either of that and Please make stretch a legendary awesome release Thank you At this point we have 25 minutes for questions. There's a mic there if people Want to come in question. There's also a runner with a mic Must be running system D So it's the plan to to block all packages with failing tests like a conscious one to kind of push people to fix their tests Or is that just because we haven't don't have the ability yet to decide between always failed and an actual regression in the test Because the letter are what we actually want to To detect and block packages on but not necessarily if a test has never succeeded. It's just plain broken So at this point we will be For those who don't know we will basically be fed a lot of packages with some issues in them and Brittany does not know why that issue occurs. She's just told there's an issue. Don't migrate it So at this point that's actually this how ci div end of net is implemented that decides this Eventually we would like to have would you talk about where we can difference between Is my package broken because somebody else broke it or because I uploaded something that's broken But the current setup that we are the prototype setup we're doing now will not be able to distinguish that Right, but that means in ci div net we could create a hints file to block this stuff only if the test ever worked So it was actually a regression Okay, by all means if you can thank you Regarding those new rules for removing packages in testing Yes, if we have those rules the last stable release Let's do in the last stable How many packages would have been affected? I don't have numbers on that. Sorry okay Of course the uh, please stand up The extremely annoying thing is that if you add auto package Tests to your package. You actually have more chance that your package is not migrating. So Is there an incentive in a way? I mean I add it to all my packages if I can but Currently there is no extensive incentive beyond you Your own fuzzy feeling in the stomach of having Sort of avoided breakage in testing As but as mentioned earlier, we want to go to a state where britney is more involved in this and can actually Reduce the aging delay There's an old proposal. That's two two and a half years old. I think Where we said we wanted to integrate auto package test with britney um And the benefit for doing it if for people having auto package test They would have a two-way two-day migration delay rather than five But I said we're not quite there where we can do that Yeah For for reproducible bills, we're still kind of experimenting a few things. Um One of the things we have not quite started at ryan now is that we're relying on to the idea was to uh rely on snapshot.dev.org to retrieve the uh Build environment and then enable the make the build reproducible Some people were raised that it would be better if the build environment would be the release What we've released in the end and so we were like pondering. Oh should we rebuild Like almost all packages after the freeze So we get package built against The packages are likely to be released with stretch There are a few things we need to think about maybe later. Maybe not stretch. Maybe next one extreme version, but this is think that We might want to consider Okay, let me know now And as a reply to what's the intent the incentive for you as a package maintainer Okay And if you once we do the actual reverse dependency Testing then the incentive for you is that if one of your dependencies breaks your package and hence your test then the dependency won't migrate So essentially you stop other people in their tracks when they try to break your package That's the main thing which also helps us with doing transitions and so But that's the carrot so um You start talking about um reproducing packages against stable by testing But as far as I know pretty doesn't ensure that build dependencies are even available In testing so we can't often can't even build things in testing against testing and hence unstable against stable Any plans to change that? Yes, there is uh, I have had an interest in doing it. I haven't done it for a while or haven't done it certainly um This is part of the things where the freeze here in The self-freeze goes in and helps because the moment the self-freeze happens things new package is not migrated so you can remove things Um, that do not have built dependencies for example, and then they stay out Um, so at this point is also a very good point for a lot of fail to build from source testing in Testing to ensure that build dependencies are present We can certainly also at this point migrate new packages to fix that That might be the same thing to do in a particular case But um, this is the point where we can do and ensure we're going and ensuring testing will be self-contained If I do not make The fix in britney yet somewhat related to the previous question, uh to lunas um Is it maybe time that we start thinking about uh, doing Automatic ftbfs uh tests before migrating to a testing So that that we uh, really only want stuff to go into testing if it's fully buildable At that time That's a good suggestion. Let me just know that um There's a question up here So there's a big push and again as talk I think later today about ppas Um, the release team got any thoughts about how ppas could be useful for Helping with release work Yes, um, we do have It's one of the ideas I didn't announce. We did have an idea for using um A ppa or an extra suite for Doing transition works in that suite. Um, which Could insist us in many ways to want having breakage in unstable where we can work isolated in The suite instead and then move it to unstable when we're done with the worst part of it um But the ideas and the drawing boards and then there isn't We have some requirements for the want to build set up here with building against different suites and So so it's not quite fleshed out yet, but if we had pbas that would definitely help there um Have you formalized the policy to Define what packages can Would be allowed to have new upstream versions Because I know at least post-greSQL has ships newer stable releases during the stable release. So Most likely it makes sense to push them as well during the freeze And I know that I would like it to be the same for Django, which isn't saying upstream policy But with that sort of started this discussion, but I don't know if you made any progress on your side and And possibly auto package test would be one criteria. It could be also Helpful here in the current site for the discussion before Yes So yes, we we do have Not quite a full list yet. Um, but we did have a talk with the security team and the srms about what packages We are currently accepting new upstream releases of doing the freeze or after the freeze Um, usually it's browsers or the linux kernel Um, so but I don't have the list here right now right now, but we are working on one Um, you have a question from the internet from irc. So I'm relying from sebastic which says, um Recently the release team member went sort of of sort of on vacation And they have not returned to coordinate the gcc five related transition again So things are moving a bit slower on the on this gcc five front because your coordination is a bit missing Uh, when will you come back to it and because your input is greatly appreciated I'm sorry. I didn't quite consider question Um, the question is basically, uh, when will you come back more actively on all the related transition? connected to gcc five because Um, it looks like you went a bit on on vacation and things are moving more slowly Because I went on vacation Um, no, I'm But yeah, I have had julian and jones and have been doing a lot of work here on the release team side And matias has been working a lot on it um So I have actually not yet been able to catch up with it But I will after the dev confere ins Or have a look at where we are But I think I think we our estimation is that we're halfway through or so So we're hoping to be done within two to three months But we'll see how it actually goes. There's a lot of things that still need to be in a mute and every in a mute takes A couple of days due to the delay and all so if you want to help make it faster Please do you upload yourself for approval of sewarding in a mute for it? We also help Hello, hello, I have a question about um auto package tests currently. I believe that c i dev in that runs against um Uh, the entirety of unstable when it run when it's running the tests and I wonder if it might also be interesting to Also try and run this at the time when you've decided you want to migrate a package against the stuff that's trying to go into testing So testing plus the things you're trying to migrate so that you can see if when you've migrated it It's still going to continue working at this point I wonder if that might also be interesting or maybe be interesting instead It is interesting But the problem is you migrate between zero and thousands of packages with each run Usually maybe only 20 or so But still if you you've decided I'm on a migrate 20 packages and then run you didn't have to wait for 20 Auto package tests to complete before you accept it um Which is which we might be able to do in the 12 hour room that britney has But during sort of the pearl transitions or stuff like that You are end up with a thousand packages that you need to test and all that might be really entangled I don't know if martin has slightly more technical answer as well Well, it's not more technical It's just looking at it from the angle of executing the tests And I suppose you you meant that we don't run the tests against the entirety of unstable Not the britney test but the actual auto package tests and that's I think it's possible in theory We could craft like an apt pinning file where we Like we exclude everything from unstable accept the 500 packages that we are trying to migrate It hasn't been done yet But if there's interest in doings if someone is interested in doing that That would be a great contribution because we run into that scenario several times I'm thinking that each block of transition So every time you decide you want to accept a package then this is a mini transaction And then each of these transactions is then fired off in turn So one block of auto hints from the easy auto hinter one like if a package can go in on its own Then you take testing you add just these packages So you dominate the old packages out of testing add these new ones in and then this is kind of like a mini release It's the state that you're trying to turn testing into now And then at this point you can run You can say is this a valid state for testing next time britney comes back and runs You say have you got the answer to this transition now? Yes or no wait or carry on Okay Yeah, I get the point the issue is here also if you start doing that you should also do the fails to build from testing Go at the same time Which would be an interesting feature to do I think it's just a bit hard to start with that So it might be for the future But I will note it Any other questions while I write could the kids wait after the stretch release? I'm not really in control of when people have kids You Okay, if there are not any more questions, I think we would just end up a bit early and then expected Yep, there's one there So there was a qa both earlier this week and one of the idea of flying around flying around was that We could do automatic removal of orphan packages probably non key orphan packages from testing Just to make it easier for people to detect that they are found and To other than what do you think about that? I don't have any strong opinion, but What was the kind of package? Non-key orphan packages Oh non-key and orphan packages which Could be interesting It just Needs a bit of thought with if you remove orphan key packages I suppose that was part of it Okay, let's take it afterwards. I'm not sure I understood what you wanted not so much a question as a comment I just want to say probably on behalf of lots of people Thank you very much the release team. We know how massive amount of work you guys put in It's really appreciated I welcome and you also welcome to join. I think we'll end it here. Thanks for coming