 Good morning. This is Adam Barrett, also known as ADSB, and he's giving a talk. Afterwards, if you guys want to wait, we have some lovely prizes in the front for people who came. So, sounds alright. Morning, and welcome to Bits from the Release Team. A quick overview of what I'm planning on talking about. Largely, updating us with where we are on Squeeze now and where we're planning to go forward from here. Quick first thing, since last DeboCom, there have been a few changes to the team, most of which I'm mostly aware of. Datto and Luke both stepped back from being Release Managers, although Luke has now agreed to join us and stay on as Release Wizard and help out with the release, which we're very grateful for. We're very grateful for both their work in Debian to this point. And we decided to formalize what I think most people have assumed for a while, and I know the press team will actually be sending out a fact for a while, and that I'm officially going to become Release Manager with Neil helping out us a second so that we have two Release Managers again, formally. We've also had a few changes correspondingly on the assistant side. Yuri has decided to spend more of his time looking after the Spark port if he needs it, and we now have two new Release Assistants, Mehdi and very recently Julian Christo has joined us as an assistant to help out. Very quick, I hope, go through the release goals. The very good definition I thought of Release Goal recently, it's a horizontal transition. It's something that's spread out, rather than being like a localised reset package spread out across the project of things that we'd like to get done for a release that won't block the release, but are still candidates for NMUs, for people updating packages to help them work with those. The first one is K3BSD, which is the first, well, the second non-Lenux port, but the first one that's approaching a releaseable state. There's still a few issues with the moment that no-ones are. DI isn't localised at the moment, so as long as you're happy installing it in English, that's fine. There's a few things you might expect like Bluetooth and Fuse that don't work at the moment, and sometimes you have to restart your display manager after boot to get the keyboard to work. One of the others was boot performance, so it's a small note. There's an interesting priority issue in that we've only got a required package now depending on an optional one, which isn't particularly great. One of the other things was moving to Dash as the boot shell to make things quicker as well, where there's still some cases where the migration over from Bash doesn't quite work properly, which we need to sort out, and there's an issue with read-only scripts. Package quality, there's recently, there's now uninstallability checks being run daily by Eidos, which they're filing bugs against packages that are currently uninstallable in CID at the moment. The archive is now also using lintian to re-auto-reject packages that don't meet certain quality targets, and we also have archive rebuilds being run several times a year, sometimes just because Lucas feels like it, and sometimes to test particular changes that have happened recently in the archive. Multiarch, not quite that yet. Still working on it there, have been some changes recently and experimentals on the app side, which look very promising, and we've finally got rid of GTK 1.2, which is a few other older libraries that we'd still like to get rid of that we haven't quite got there yet, but see any help on getting rid of those, welcome. Full IPv6 support is the release goal we've had for a while. I think things are improving, but we still don't have, we still have things that don't quite behave properly with IPv6, which means sorting. We did have a release goal to have the new d-package source formats used by default for all packages, which has now been dropped, obviously. We still also work on the new formats, and I think Raphael's still encouraging everyone to use them, but they're not proposing to use them as the default for all packages anymore. We're getting rid of Libtable LA files going very well, but there are still quite a few packages that need some work on that side. And finally, large file support, which mostly getting there is about a dozen open bugs at the moment. So, where are we with transitions and what we've been trying to get done? In terms of what's already been done for Squeeze, that's a very incomplete list, I realize this, but we couldn't fit everything on, so we decided to pick out a few things. We've got new versions of KDE, Noman X, Python 2.6 by default, which was fun, but finally got there, and the new versions of DHCP and dependency-based boot to allow things to be parallelized during start-up and hopefully, again, make the boot process faster. We've got a few things that... that's roughly where we are with what's still ongoing at the moment. Not looking too bad, I think. So, how can you help with the release and... First thing, so I know it sounds obvious, but please don't introduce any new transitions at the moment. We've still got to work out, sort out the ones we've got and get those into testing and we could do without adding new ones, particularly as they have a habit of getting tied together, so we end up having to move three or four different transitions in at the same time, which takes longer and makes life interesting. If your package is involved in the transition, please don't upload new versions without talking to us if the transition hasn't finished yet, because you could delay it or, unsaid, always get it accidentally tied together with an existing transition. If you're not sure, please ask. We're quite happy to tell you. There's also courtesy of Medi and Stefan Glondu who worked with us on a web page where you can keep track of what transitions are ongoing and which package is involved in them, that sort of thing. Don't upload things to unstable that you don't want to be released, that's the primary one, I think. Unstable at the moment should be largely viewed as things that we want to migrate into testing and therefore into the release. If you don't think your package is ready for the release or shouldn't be released in the form it is, don't upload it. Obviously, again, obvious, but everybody's been doing a very good job at fixing RC bugs recently. The BSPs, various people doing their own personal bug squashing contests and, of course, the DebConf bug contest, which I assume there will be some results for it at some point, and testing upgrades between lenient squeeze, finding out what doesn't work, particularly so that where there are things that we know about that will have to be, we can either get them sorted or, at the very least, documented in the release notes so that people know what to expect from upgrades. There is an upgrade to report pseudo-reports, the pseudo-package in the BTS, which you can file those against, which will help track this sort of issue. I think most people know this, but just as a brief recap, if you do want to get hold of this, there's a number of ways you can either email us via Debian Release at listdebian, find us on IRC, there's generally somebody around, most times, or things like bin and use transitions, proposed updates, unblocking of any packages, et cetera. There's scripts in report bugs that will help file bugs with the right user tags and the information that's needed to make it easier for us to track things. I'm getting a little faster than I expected. So, a question we've been asked several times this week is, when are we freezing them? Which I know there's been a certain amount of speculation about this week. We looked at it, we've had a number of discussions about when we should freeze, and there were two things that, two particular things were on my mind, one which is state-to-current transitions and housing, we think we can get those done, and particularly without getting them blocked and unstable by other things, since we've got a multimedia transition that's blocked by SQ Lite at the moment. And ICU, which is actually blocked by Ruby of all things. Some of you have heard me moaning about this a little, but it's getting there. And the number of outstanding LC bugs, which is still high in the amount of light, but very much been moving in the right direction very much recently despite the attempts of some people with Lucas filing yet another set of build failures and the, oh yes, the flash don't, flash sources missing the various flash movies, things. And coming to the conclusion that the easiest way to get all the transitions done was to not have any more transitions and just go with what we've got outstanding and that we're happy with the way the bug count is going and how things are improving. And basic conclusion we came to is that we are freezing now. There's still a fair bit of work to do. We said earlier we've still got transitions that we need to get done in unstable, but we feel it's going to be significantly easier for everybody in particular if we can get those transitions done and then out the way without having to worry about, well, us and anybody else having to worry about whether a new upstream version of something is going to get in the way or anything else, as with previous, well, as with Lenny, anything that's in unstable now, assuming it gets to a point where it would otherwise have transitioned, will get a freeze exception. So there's no need to worry about that. Well, as I'll see bug fixes. Anything else about that? If you're unsure about whether something is suitable for upload to unstable now, again, please feel free to talk to us. I know it's sudden announcement, so if there were things that you were planning on uploading very soon now, then again, talk to us maybe that we can be a little more generous for the short-term terms of that. And of course, where do we go from here? Well, that's the plan. It's a slightly simplistic version of what we're going to do, but that is largely the plan. Finish off all the outstanding transitions we have or, well, finish one way or the other. Either get them done or, if necessary, decide that we can't, but I'd prefer to get them all done simply, fix any of the remaining RC bugs, and then release. And then I'm going on holiday. So that's about it. Slightly early in the night plan. Any questions? Oh, dear. It would be you first, wouldn't it? Okay, so we freeze today. Yep. Do you have even any suggestion of when you'd like to release? I'd like to manage by the end of the year if we can do it. Cool. And are we thinking about doing a squeeze and a half release at some point? I guess that's not yet. Not yet. Cool. Hello. Hi. What is the next code name for a squeeze plus one? Not decided yet. Probably not Debian Barbie, but apart from that. Anyone else? We just stunned you all into silence. I didn't follow up all the discussion on Debian release. What will be the schedule for the freeze? Will it be incremental as in the past, or will it be intent to be faster than it used to be in the past? What will be the schedule for the freeze? Will there be some steps or? At the moment. Like usually I would say or something new. At the moment everything is just frozen. So we've been here before. I seem to remember that last year you promised us a release in March. And there was a press announcement. And about two days later it was, no, no, we misspoke. Are we going to have a retraction in two days in the archive open, or what's your level of confidence that you can hold to the freeze, bring the developer population with you? There's already been a few comments on IRC of what? What? How confident are you that we can pull this off? I think it's a great idea. And I think that someone needs to stand up and say, we're doing this now, but you're going to get objections. And how firmly are you going to hold your position? Realize this. We're frozen. I know. We were fully aware when we took the decision, particularly with not having finished even the bits that we wanted to get done yet, that it was the right thing to do, and that we're confident we can get what we need to do done, even on the freeze. Does this mean that we will not be doing a Perl 5.12 transition for squeeze? There's a correct answer to this question, which is... Yes. That was the correct answer. I think one of the comments is why we've announced it now rather than giving a lot of notice. There's sort of two parts to this. Last year we gave a couple of weeks notice and we found that everybody were suddenly rushing to upload all their last-minute changes and to beat the freeze deadline. And that included using things like high urgency just to ensure that it doesn't spend time in testing and gets... Sorry, it doesn't spend time in unstable and get through to testing. A second bit is the risk of losing my entire wireless connection if everyone checks their DDA mails. There's a lot more details in there. And one of the things we have is that we will be fairly forgiving in the first couple of weeks. If there is a change you really, really, really need in testing and you haven't beat the freeze deadline, then come and talk to us. We can help get packages into testing and what we actually want is just to get the best release we have out there, get the newest software. And we think that by freezing now that that's the best way of doing that there's something you really, really, really need. Then come and talk to us. Hello, I have a couple of questions from IRC. And Luna is saying if freeze equals no new packages or is there a small tolerance about it? And then Siego is also asking who's responsible for the names of Debian releases and how is it decided? In terms of new packages, as Neil said, it depends certainly not, now it's not time for major new upstream releases, things like that, but there are changes that you want to get in that otherwise probably might not meet the freeze in the short term then certainly we're happy to look at... Oh, in which case, no. I think that's... It's a very convincing argument for doing those and it's largely been one of the few perks of being a release manager that you get to choose the name for the next release. We haven't done it yet, no. We've decided we'll let you know. Any more questions? Anyone? So when's the next release? If there's no more questions. Anyone at all? No? I guess that's it.