 I will Replay the comments from the IRC if you have any comments you can shout and you can screen and he can repeat the screen Or if you can wait for the mic He can run so if you're gonna say something more than a screen, please wait for for the mic So there we are Thank you very much It's good to see so many people here. Normally I complain about The first every single one for the last three or four Debed comps this has always been after the cheese and wine party in the morning So we have about five people sat around looking very hungover And then I'm one of those people who has to get up on stage and give a talk about about the release process Now this time it was slightly different. It was not after the cheese and wine party But also on the first day of Debed comp so writing these slides happened a few hours ago So have to bear with me if there's any any spelling mistakes My name is Neil McGovern. I've been involved with Debian for the last 12 or so years in one form or another everywhere from policy writing from the web apps policy to the security team and Lately in my incarnation as one of the two release managers we also have here Adam Barrett who's at the front and he's going to give a little wave and Phil Kern who's in the green t-shirt halfway through So if you have any any questions as well, then they'll feel free to ask us these two people as well Now a quick overview of why I'm up here and Adam's not Apart from he sort of twisted my arm behind my back until I did it Is we sort of decided that we're going to split the release management into two a technical side So dealing with transitions and bugs and making sure that happens And then a management e-type side of sort of communicating with the project and talking to people And so that that is for my sins my my job So so a quick outline of what we go what what we're here to talk about We've had a brief team change. We've had another person come into the team, which is fantastic a Quick talk about the new things that are happening wheezy a little bit about the free And and how it went and and the sort of issues we saw around time-based freezes Which is a thing for people who don't know of a new thing We're trying this year on how we manage freeze policies and and then how You can get your package unblocked what our current thing that means we're frozen actually means And then a little bit of information about when we expect to release and and that sort of Area and then some details on on how to contact us So firstly I RC Nick kibby Cyril has joined us as release assistant and is doing a fantastic job I'm sure if you've mailed the list with unblocked requests or with transitions Then you then you've come across him already But of course we always need more people more people to come and volunteer and help in the release team It's traditionally been a fairly small team anywhere between Two to about six if you're so so more people helping in this What can be a very manual quite intensive task is certainly very very useful and Certainly see any of us at the end if you're interested in helping out with that So wheezy we have now frozen which means we are not having automatic Migration of packages going into testing which is starting to give us an idea of the sort of new things We're going to see in wheezy So we've got KD 4.8 Noem 3.4 new versions of Python and a 3.2 Linux kernel So this is quite up-to-date stuff that that we're pushing out and hopefully will be in in the In the next release, which I hope will be fairly soon But one of the main points here is that we don't actually know what's going to be there because there's I think at the last count 39,000 binary packages or so in a debut release So we don't know what we can tell everyone and and tell the world about what's in our latest release As you know, I think today and we're going to be having the new desktop base artwork going which will be quite nice so we'll have a new look for that and With my press team hat on I've already had requests from Journalists saying what's going to be in the new release. Can you give us screenshots? Can you show us the really cool things? And so we once again going to be using this wiki page at the bottom Which is wiki.debian.org slash new in wheezy and I'd encourage everyone if to go and put in really interesting stuff there Things that going to be new in wheezy and really quite exciting for the users to to really help show what's going to be in the New release and and make everyone Really excited about it then that'd be great That's also the place that the press team are going to be basing release announcements off So what we've got coming up. So that's the really the place to to put it all Sorry, I mentioned the freeze we last time at debcomp we had a Few we've had a few different interesting announcements around freezing and when we do it this they start in debcomp 9 When we said we're going to follow Ubuntu and everyone said no, don't do that And then we had a issue in debcomp 10 where we said we're throw and despite males to DDA saying we're freezing really soon now We said we're frozen During the release team talk and that didn't go down very well obviously either So we decided to use a time-based freeze So we say in advance when we're going to freeze and and there's a few advantages and disadvantages to that And it's something we decided to do. We announced this About well, we announced it in June last year So so we've known for a while that the freezes happening and we decided this date in a sprint There's been some discussion about why did we pick June and why not different dates and and to be honest There is no good answer If you pick up any single month or any single date It will always be inconvenient for someone we pick the best one We can and and when we think would be sort of good in the in the sort of cycle to try to try and get things together And and this is really to help give maintainers a date and a framework that they know they can can release with So they should know Far in advance of when we're going to freeze and so should have everything ready done in plenty of time To make sure that that that happens How's it going so far? Well Most of the large transitions which we asked for were done. There were still some which weren't Partially due to time pressures Making sure that we have essentially enough people in the releasing to handle each of these transitions a transition happens when Somebody uploads a new set of packages with a API break or an ABI break and essentially have to rebuild everything that depends on it And one of the issues is that all of those packages have to go into testing together to make sure it's all remains compatible And that often requires a bit of hand-holding and and just making sure that you sort of make sure it's in the right place to To all go in together and and and you have to handle that and that just requires manpower of someone to look after it And make sure it works So we have had to unfortunately postpone some transitions There's been a there's a few I think Libpng was the the biggest one that that we just weren't able to get in in time due to obviously this the size of that But obviously we tried to do as much as we can and we and one of the main issues We saw is we still had a lot of last-minute uploads and things don't really at the last minute as in major changes a few days before we freeze or Various other issues around that because people said oh well, we haven't had time to do it Because they forgot about it or something Another issue there is we've had a couple of very large Transition changes very shortly before the release and And that caused a quite a few issues as you can not very well see on the graph The green line essentially is the number of RC bugs which the release team are interested in which happen each release We were going down a rate of knots and that was excellent and all wonderful And then there was a couple of breakages that that happened And that sent us right back up and it's now got back to about the same level there So I'm not we're not entirely sure and we're not going to think about until after we've done with the release on how we manage That sort of transition based policy because things can break quite horribly Just before release I'm actually privately hopeful that We That is hopefully we'll just get better each time as maintainers get used to when we say okay, we're freezing in say June 2014 then we will freeze in June 2014 and Hopefully that will start to become a lot more Accepted and people will start to realize that when we say we're going to freeze them We actually are so doing major changes the the month before Are just something that you really should try and avoid because it's going to delay everyone and one of the aims of the time-based freezes was to try and ensure we have a Short release and that that's really down to the number of release critical bugs So at the moment we have a load of stats. These are Ptolema's Stats which you produces every week which are fantastic the main number at the bottom there is the 603 that is I think higher than we've ever frozen with before and Not somewhere where we would normally freeze which is what one of the reasons that has come so late in what we said originally It will be in June 2012 we froze on the 30th of June 2012 in the hope to just try and bring that bug count down as much as possible because that is still very very high for a freeze and We essentially just need to try and get that down to to actually be able to release there's a lot of talk about How perhaps being freezing harms unstable or various other bits and pieces and and the answer to that is is simply the Sooner we get the freeze out than the sooner ever sorry the sooner we get the release out the sooner the archive can be unfrozen and As part of that we've got the Our freeze policy, which is when we're going unblock pod and packages to to get into the release We're going to try again a gradual freeze because we thought this went Very well last time So the sort of things we're having at the moment the accepted things into the release will be RC bug fixes fixes for release goals Which we've set up a while ago There is going to be a potentially new sort of release goal, which is going to be rebuilding a number of packages with exetting Compression to try and get things to fit on the first CD anymore at the moment because otherwise we're going to have a problem Essentially getting it gnome onto one CD So there might be a few NM use around that but that that's sort of a side issue and then trans important bugs For Optional extra packages and those need to go through and stable We do this to make sure that there's the maximum amount of testing available and that everyone Really gets some exposure to that and you get that that handling going through and stable Into testing in the way the debbing QA process really works well And then finally translation and documentation updates. These are normally very low impact I should point out that as the freeze goes on The sort of bottom line will go up on this So we will start to get to the stage where we are eventually where we only have RC bug fixes only and that's highly targeted RC bug fixes That are being allowed in as we get closer and closer to that release date So when do we release? These will have increasing numbers of complexity depending on how much time you spend in hash Debian So it's real soon now Certainly compared to to what we've done before sooner if you help Which I'll get on to in a second and one which I made up Which is when the release critical bug count reaches zero? Which is the actual point in which we release and that's the important one to bear in mind So how can you help? Don't introduce new transitions. They they break things horribly in many many ways earlier I mentioned things have to go through unstable If it's involved in transition it can't This means the package is not going to get tested as well and as a consequence. We have to do things like Do a really thorough review on it and this just takes up amount this takes up time and The amount of time it takes up simply means we can't process as many unblock requests and the freeze takes longer So doing these things which you say don't do Means that if you do the freeze is just going to take longer because we don't have enough people to to do All the reviewing that we want Try not to upload things into unstable that you don't want released in wheezy Because for a similar reason this is what we're going to be basing the next lease off and then trying to migrate things through into testing Make when fixing RC bugs, please everyone keep doing that. That's actually the key thing which everyone should do Find an RC bug. There's there's 603 at last count certainly out there. There's plenty around to do that That's not a problem. I think if everyone at dev conflicts to RC bugs tomorrow, then then we can release by the end of dev comfort should be great But it's trying to get these these sort of things we really need to get those down because that's the major issue That is going to hold us back Testing is also very important. We're starting to get stage where we need to test migration And upgrade and install abilities and then things like that to try and get make sure that the user experience is great From when they're trying to go from one release to the next and and tell us about any problems that you do have and Finally, I'll mention this this link at the bottom, which is currently a Debugs page with nothing tagged but over the next few weeks or so that will start to fill up with a number of user tags these are We easy blocker tags, which are bugs that will need to be fixed before we can release There's ignore tags, which we're going to essentially ignore for this release because they're minor or we We don't think that they're actually Either release critical or for this release or it's something that we're just not going to block over and there's will remove tags Now these are for packages that we're just going to remove from the release Which means that if people don't fix those packages, they're not going to be in the release Similar to last year. We've and this year we're trying to be fairly Straightforward with our removal, so we're not going to delay Removing packages for months and months like has been happened a number of years in the past and things will get removed because It's especially if they've had release critical bugs that have just been ignored for a long for a long out of time They leave packages if they're not very popular even if they're important for one particular user developer Then those really need to get those RC bugs fixed and hopefully we'll be and we'll be using those tags to to try and increase the sort of visibility of what we're doing there So quick methods of contacting us on how to get your packages released there's the main enlist which is Debbie and release list dot d dot oh IRC is hash Debbie and release And these are great methods of contacting us certainly really pop along and see us and talk to us about Anything you want but the key thing is They may not get your packages Unblocked if you write a debt mail to Debbie and release certainly at the moment. It's in as you can imagine It's incredibly busy Because we have lots of people asking for unblocks and things like that and there is a fairly high chance well, certainly if it's me that I'll just miss your mail and then You'll essentially be ignored for a while as as no one will pick it up so the best thing to do is use report bug against release.demon.org and That can handle things like your binary NM use your transitions your unblocks proposed updates Anything like that and that's in a single place where we can track it and and and make sure Things happen and and they get get through otherwise. They quite frankly won't just and just finally a Quick thanks to Collabra who are my employers and paid me to come here. So that's that that's a big thank you for them and That is as I explained probably the the all the slides that that I had for the release because I normally like to leave a Fair amount for questions for the restock this time I haven't actually Announced that we're freezing now or that we've released or anything so there might be a few fewer questions And I normally get in a little bit less heckling But I thought I thought I'd leave it there and see if anyone has any particular questions either on the release or Stuff we're looking to do in the future or anything at all really so I'll certainly open up the floor to to any questions that people have Sorry, what was that? The name of wheezy plus one Well, so we we're trying to be an ad and we're having this debate about when we when we should do this and and have At all we we haven't decided yet Is the basic answer? with think With thinking of Announce it may be in about a month's time or so we normally do it last time we did it about a month after the freeze But there's been some ideas Kicking around there's been heavy lobbying from the Zerg and the shark lobbies have been coming to see us and say Please call you the next release sir who was the some alien or something that is the big alien guy And shark is just the key ring maintainers Referential choice. I have been threatened with having my key removed from the archive if we don't pick sure But he did that last year at last time as well So it's probably not gonna have or maybe he hasn't I haven't noticed. Hey, you don't know Yeah, apparently that's that's what I get for being management was was the comment there Anyone else? Yes, what about the claw the claw that was also another suggestion from Joe somewhere Well, that might make some quite good artwork for t-shirts that I'm not sure about that one either What what normally happens when we pick a release name is we try and think up something that hasn't been used something That's quite iconic would essentially look good on a t-shirt and then we come up with this great name and we Mention it to the rest of the release team and FTP masters and they say that's horrible. You're not using that and Then we go, ah, right. Okay fine. So we need to come up with something else and so then eventually we find something at People seem to like it and works quite well Anymore So the question not actually ready to the name of the next release. We have a history of burning out release team. Yes Given that Zack talked yesterday about Institutional memory and learning to do things and given that we're trying time-based releases for the first time Do you think that a substantial portion of the current release team will still be present in two years time for the next time Be as freeze Do I do I think they'll still be a substantial portion present in do you think we'll have enough of the current team present in two Years time that the the lessons we have learned from our first time base freeze Will still be held within the release team people will still know what went wrong this time What worked well and what we need to do better for next time Not asking any of you to commit to being here But do you have a feel for how burned out the team fables compared to previous years or previous release team? Hi, that's likely to work in the future. I Think it's been helpful to have a time-based freeze so that when these things do go wrong and when people When there is things that the big change is uploaded the last minute We can point at people and say look we've told you for many a year and that this is happening now It does raise a level of frustration that this is still happening In terms of ensuring that the memory continues to the next time One of the things we did after the last release is we had a sprint with a retrospective and documented it all and Put it all online to make sure that there's something that even you people can come and look at and there's a lot of Documentation going on from Nils to make sure that that this sort of stuff is documented So I'm hopeful that even if that does happen. I don't have any particular reason Reason why it should at the moment Especially if we try and get more people involved Because part of the reason that people have been burnt out in the release team is that there has just not been enough people involved So it's it's fallen all the work has fallen on the weight of a very few number of people and and that's been the main issue there So I think if it does then Hopefully we've got something in place to try and make sure that the ideas and what's gone, right? And what's gone wrong will carry on From ARC crazed a candle as How does one see the tags on the packages being discussed? Sorry Yeah Where how does one see the tags on the packages being discussed? Yes. So this is only for release critical bugs if you go to the Deb dot li slash wheezy bugs then The whole list of bugs will eventually be on there and we'll go through and tag them all and they'll be They'll be documented in in there on to what's happening There's also a few other tools you can run on your personal desktop RC alert is one of them which will tell you about release critical bugs and packages installed on your machine So hopefully if it's installed on your machine, you might care about that package So you should probably have a look at those RC bugs and hopefully go and fix them Yeah So the real answer to Jonathan's question there is in fact that the entire release team will still be around They'll just all be wearing wizard hats Um, but I do have an actual question Um, so one thing I've noticed in terms of how we deal with fixing of release critical bugs. I remember tbm four five six years ago had it was very good at organizing Bug squashing parties that had a a distinct um online component to them And I kind of got the impression that we aren't doing that so well anymore where There are a lot of people organizing bugs washing parties for Wheezy In one locale or another, but those seem to be taking place only in meat space and there's no Hash debbie and dash bugs doesn't really get used for coordination And I'm wondering if you have any thoughts on If that's a problem that that's hurting our rate of fixing RC bugs and if so what we can do about it Or one of the main list Suggestions that I'm sure you know is is that we all just go and create a google google hangout or something like that And go sit on there and fix RC bugs, which I'm not sure is the right solution But I do think it is quite important to try and get more people involved in RC bugs Squashing and if we can try and get more people to come along to the Even virtually to a real-life bug squashing party then this would be a really really good thing Um Probably one of the reasons that this hasn't happened again is um the amount of effort it takes to organize an RC um A RC bug squishing party Certainly it's when you're actually thinking about oh, I need to make sure there's venue Place of somewhere to people to stay and the rest of it then you don't necessarily think of oh And now I need to sort out making sure that there's like an online presence for people to come as well um It'd be really good to happen as to the answer on how we make that happen without using Um proprietary or closed solutions or things that people aren't comfortable with. I'm not sure at the moment Hi For translation work, what's the policy during the phrase how how much time We have the under release team accept the new translations um About that long It may not be to scale but about that long. Um, so So there's a few there's a few times scale then here. Um, one is um, how quickly is it I'm going to take us to respond to these bugs and things like that. Um, which is as soon as we can Faster if more people come along and and try and help out things Certainly doing some basic triage from which anyone can do To try and get an idea of what's going to be in these particular bugs Is very helpful for bringing down the the amount of time and again, these are all helpful for actually getting the release out quicker as well So I suppose the sort of answer is which is a bit of a get out answer is is as quick as we can So i've got this brand new Package that's just about to go into new can I have a free's exception, please? Well, it depends which Um, it depends which package it is if it's if it's your special debbie and cd package Then possibly all the new key ring archive, but generally No We've had a few people who said we've got a new package. Can it just go in? I've just missed the freeze and to be honest We we announced the freeze Over a year ago We've been quite clear that this is when we're freezing and people need to make sure stuff is ready in time Um, and if it's not then i'm sorry that then there's next time and hopefully part of this will be able to Make things more predictable more reliable. So people won't be worried about when the next release is going to be Um, and again, it's it's our job. Um as a release team to try and help the project Release efficiently as a whole release not just particular packages And you I've been sitting here trying to process your illusion to google plus hangouts and so forth And I I realize this is a completely radical idea and it's liable to upset all sorts of people in debbie and but Why don't you use hash debbie and dash develop on the irc for something that's actually useful? And have that be the place we all hang out when we're doing bug squashing parties Yeah, um, I have No particular problems with you with using any channels and trying to get more people involved in squishing bugs um Releasing is a thing that the project needs to do as a whole Where in the release team ahead help it and try and Massage it along and and try and happen But if if developers as a whole don't want to release debbie and or aren't interested then it's just not going to happen There's not enough hours in the day or people in the release team to get those 600 odd rc bugs Fixed or well without just removing half the archive And that would probably not be the the most user friendly option that we have there um Getting more people squishing these it means we release faster the freeze is shorter And then we can move on to doing really exciting things again It's essentially in everyone in everyone's hand to try and help this along No more questions. I think that's it Are you sure? I always get a little worried when we've got a release assistant. So putting their their hands up saying yes, I'll ask something I don't actually want to ask something. I just wanted to point at another slot today at 4 p.m. Yes Where I will put up A little description about the tools we use if you want to get involved If you want to know what goes on behind the scenes because this is more about the big picture not what we are actually doing So if you're interested it should be rather buff like so if you want to ask questions, they have feel free If you just said, you know that it's happening today at 4 p.m. Yeah, so yeah, that's today at 4 A buff on how we release things and the tools involved and how to get involved and do things It'd be great to see certainly this many people here And everyone here volunteering again to to come and help And be on the release team and to squish all the rc bugs because that would be brilliant I think that's hopefully it then. Okay, so that heavy on thank you. Okay Thank you