 Welcome everybody to the release teams keynote. This is Luke listen to him so and the release team stock as you probably see in The schedule was originally Datto stock But we made it a team effort. So he prepared the talk and I'll give the dog Yeah, yeah, I prepared the slides he prepared the notes for the slides so and let us start with the new Release assistance You have Adam Felipe who's walking away and Yuri who is currently in Ireland. So So we hope that these new Release assistance will make the life of the current release team and especially the release managers Better and to make sure that we can as release managers More focus on the coordination instead of ground work speaking of coordination a Lot of people already asked me and the release team in particular and What are the release goals and how are we going to track them and things like that? Well, and the thing is The way we did it in the past and the way we did it up to now Will change a bit We don't want to track them anymore On release dot devion dot org, but we want to move it broader we want to to make sure that everyone can participate in tracking the goals in helping to solve the issues and The only thing that then remains in the release hands is to make sure that people will help tracking the goals will help solving the goals and Will help of course updating the wiki pages So for each release goal we intend to Make a wiki page with a clear description of the release goal and more importantly probably with a Clear overview of the status and the list of outstanding issues but also Some kind of milestones so that it's very clear Where we want to go how we want to and how we want to go there and and of course coordination all also means communication, so You can expect us to communicate more and also to communicate better And that means of course the whole release team within the team itself But also with of course with various others teams like FTP masters And but also with packages Translators users document writers to press and things like that Then an overview of the release goals we currently are thinking of including First but probably not the easiest one multi-arch So probably many of the Members of the audience went to the talk about multi-arch Multi-arch will probably not be complete for squeeze, but we want to have basic support for multi-arch and squeeze Then one another thing boot performance one of the main blockers for that was the move to Default system shell dash, which happened during that call And there are still some little issues to solve there Regarding dash, but they will be solved soon. And and of course there is more To tell about boot performance, but I guess We will work that out when we create the page and when we set the goals Then Other really important thing is of course high quality packages and that means Few parts clean packages. So being able to easily install upgrade and remove the package again but also For instance that no package recommends No package in main recommends on the package outside of main That if you try to build packages twice or three times in a row that it still works so That are of course Very measurable things, but we want in general really high quality packages Then one thing that we also want to have is support of new package formats It looks like It will be difficult to make sure that we will already be able to use the new package formats in squeeze but we really want to Have that support ready so we can use them for squeeze plus one Another thing is support for future compilers And the thing there is that we want to know Really in advance if packages will fail to build or failed to Be usable with new compilers. So like The new GCC the new python the new pearl things like that Another release goal is to finally get rid of some old libraries like GTK 1.2 and then last but not least we still Strive to get zero RC bucks Currently Currently there are really many open RC bucks if I'm not mistaken. It's over 1,000 That's only one per developer but it's more So every developer and non developer please help with fixing the RC bucks Even if it's not in your own packages file patches Work on non maintainer uploads. Please Try to start fixing the RC bucks So now a different topic The release team thinks about going to a time-based freeze Why do we want a time-based freeze? And Till up till now And we had some releases that took a whole long time After that we had at Shanlani which were Which targeted a specific date But of course the most important thing is that we have a high quality distribution So we don't want To release when we're not ready so to But as many other projects benefit from time-based releases We want to try something that would work for us That is time-based, but that would still focus on the quality And so we thought about time-based freezes One of the main benefits of time-based freezes is That well every developer knows beforehand when will will freeze So every developer can make his own plans can make sure that everything is ready in time and That he won't hurt the other developers plans and that everything should Should be finished within time And of course having A time-based freeze should make the schedule more predictable and As I already stressed We don't want a time-based release because we still think quality is more important than the timing of the release So if we would do time-based freeze What would the timing be And We really think that that comes should not fall in a freeze. So so that at that comf you can do Really new stuff you can still break things you can Then after that comf you still have time to fix the things you broke and You have time to integrate your changes possibly disruptive And As we saw for etching Lenny a Spring release work quite well so Taking these into account. We think a Freeze timing of December would be a really good idea We're coming to that then the freeze timing so what year and One year After release is very short right because if you freeze one year after release And you really want to release soon after that then the release period will be very short and People will complain because we only support upgrading to the next release So then they have to upgrade to the next release and probably the release afterwards Three years is very long because you have the freeze of after three years then you still have The the time of the freeze itself So the release period would be longer than three years Which would mean that security support would last more than four years Possibly even five years, which is very long and which is currently Not in that well in Debian not a thing we want to do so About two years is probably the best answer No for squeeze For squeeze we don't want to wait We want to have the ball rolling we want to have To make sure that developers That think that time-based freezing is a good idea To start working on it now We don't want them To have to remember next year that that we want to do time-based freezes And another thing of course is if we get the ball rolling early Then we can also open the door to closer collaboration with Ubuntu because Ubuntu and The longtime support releases they happen in even years So that means if we would freeze in December 2009 And we released in 2010 and The longtime support Can be in the same year It would also mean that we can use the same versions or almost the same versions of packages within the releases of both Ubuntu and Debian Which means of course that it's more easy for Security people for maintainers to work together on issues in stable or in LTS and Of course currently Debian releases happen in odd years. So we think That freezing in December this year Would make sure that We get the ball rolling we make sure that developers Show the release team and the project that we really want to go for time-based freezes and For closer collaboration with Debian Ubuntu and maybe others so Let's start the discussion Are there any questions or remarks? Noah Small comment about the boot system I saw you listed the faster boot as a release goal and that's definitely a good goal to have I've been promoting dependency-based boot Sequencing and rewriting the boot system to become event-based just to make it clear That's not to make it faster. It's ma it's to make it reliable and fix a few bugs in the current system Faster is a bad byproduct Thanks my question aims at Time so you want to have freeze every around one year That would make it net more necessary to Get our transitions done faster because the currently asked some transitions dying around for For some months and Blocking the rest of development Well, and then have another position after that and then have another position after that to make it fair clear we we want to have a freeze Two years after every release, but we want This time to be an exception to make sure that people get used to it that people show that They are really interested in getting there Yeah, but My point is general one because but you talk about one year. Yeah For this time, but I Don't know you need to get to this just done faster if you we really want to keep the time So maybe I'm just getting old but help me with the timeline for just a second So if we do a freeze in December, what's the expectation for an anticipated attempted release date? Well, it depends of course on the developers how Understand that but if we all actually behave the way we're supposed to behave what yeah The first of January No, probably not because Freezing in December will mean that Everyone has all has done all the changes he wanted to do for his package has included the Sometimes the new versions of the packages he wanted So it will mean that we still need some coordination and integration Which will take a couple of months So if we would I'll be If we would make the time-based freeze in December We think that a freeze of about three four months should be doable Okay, because of course the thing that I care about a lot that I've talked about in the past is The negative impact on our overall development process when the freeze drags on for too long And this is not a complaint to the release team. It's a complaint to all of us for not You know being serious enough about you know What should happen during the freeze process so that we can actually get to a release but I you know, this is something I'm sort of this is the other part of that equation that I spend a lot of time thinking about Of course one of the most important things that still happens during a freeze is fixing the remaining RC books So As I understand it the plan is to have roughly one one-year release in order to do this synchronization with Ubuntu, I don't think that's a bad goal but a one-year release cycle is a something that we've not really done before and Also something that you know speaking of somebody who likes to run stable. I don't quite fancy doing upgrades every year Even just once would it be worthwhile thinking about doing two 18 month releases? rather than going straight on for full-on attempting a one-year release Well, the thing is if you would do two two times 18 months you don't have the The main benefit anymore because it's not predictable anymore when you freeze Now it would be December and in two years December So it would be very clear for everyone that a freezes in December in the odd years So does the the freeze in December? include the stage freeze that we have done before starting with two chain and then base and then continuing with the rest or is it going to be total freeze or Well, we think about a total freeze because having them in stages confuses too many people Okay There seems to be a bit of confusion as to dates and times and things as I understand The idea is to freeze in December 2009. So the December coming Approximately three or four four months later release and then freeze again in December 2011 and 2013 and 2015 now if it takes us two months to release great That means we have a longer Release cycle for next time if it takes us six months to release then we have a shorter release cycle next time But the importance is that every developer would know when the freeze is coming So every developer would know when is a good time to upload disruptive changes And when they should start to be more careful and it would hopefully Make the actual free cycle shorter Having them separated by two years Would also mean that we have one that comes where we can do whatever we want and the next step comes had to be a bit more careful and Already thinking about having a freeze in December I guess I'd like to state the obvious. It just seems way too short to release to freeze in this coming December with the last release in the second month of the year There are large institutions which just cannot feasibly upgrade in that time frame and Even if the long-term goal is to get further out, I'd be really concerned about the impact on the organization doing that Hi, I'm just passing on the question from Tom vehement on IRC he's just concerned His question is so how do we cut 30% of the freeze time? How do we cut 30% of the freeze time? Well, if everyone would make sure that We have a proper freeze in December The freeze time should be shorter and 30% would then be a reasonable goal I'm wondering what impact the one-year release cycle which I think is a good idea if we can solve the problem of institutions Not being able to upgrade that often Maybe that could be solved by an exception to the security support policy to support To support at one more year, but in any case We we I'm wondering what impact the one-year release cycle would have on the ability to get K free BSD I 386 and K free BSD and a 64 into the squeeze release as fully supported so firstly out of the same comment as as Jimmy did about security support the Blocker is blocker for large organizations is not particularly when the next distribution is released it's when the one before that stops being stopped being supported and We might be in a position to smooth the The way for that a little bit. I expected it would require some preparation and security team The other thing I was going to say was that as a as a previous release manager Who presided over a very long release the I think we've got I think we've got into the habit as a project of Expecting very long releases and we have some psychological difficulties now with the concept of shorter ones the This this tends to show up in terms of people making very long-term plans that involve things being broken for a long time in between and so on and I Would expect a one-year release to be painful on the other hand it might be that it would impose some useful discipline on People that would Lead to better habits in future and might make things easier for ourselves Perhaps is an alternative of extending the release is Sorry next thing the release is providing a path to upgrade from old state Across two releases it shouldn't be that difficult to support It basically means we just need to keep transition packages around one more cycle than we normally would I realize it would be definitely a new policy to be able to go from now very old stable to stable But it may be worthwhile especially given the frequency of the of this new release Yeah, I I've been in One of the customers have seen is is a rather large institution that takes a rather long time to Roll their own derivative of Debian and they are currently still evaluating Lenny a year literally cycle nice and fine, but they can't evaluate a new Distribution every year because they take a year to evaluate it. The reason they use Debian is because that works for them In some places you so indeed it's needed to jump if we have released every year Then it's needed to allow people to jump a release But of course the intention is not to do a release every year Because I think that will make it very hard for the release team and the project To just keep up, but I think a one year Exception so a one-time exception to make About one year release should be doable also for large institutions and things like that for large distributions and because if we make sure that For this one it would be easier to go to skip the one release and It should be doable Hi So earlier this week Steve Langeshek had a talk that sort of veered off into the question of How do we build consensus and how do we deal with with negative feedback? and One of the things I realized that one of the things that came up in that talk is the importance of empowering people to make decisions because It's very hard to get the entire project behind something and so the I think one of the things to remember here that's very important is that We should empower the release team to make this kind of decision whether it's one year or two years now whether it's Two years or a little bit shorter or a little bit longer in the future I think it's we all need to say that That's within what we expect the release team to decide and that it's okay for them to make that decision. I think it's fine For us to Basically give the release team feedback. Well, please consider k3 BSD. Please consider long You know organizations with long least lead time please consider a lot of things and I think it's fine for us to give them things to consider But none of the objections I'm hearing today are so strong that I think the project should overrule the release team and so I'd ask people to to Especially if you're if you're just giving input and you're not trying to say the release team is way off in the weeds to make that clear and I'd also ask you to be very very careful and Double-check and possibly even triple-check your objection before you state an objection you believe is so strong You're saying you think that the release team is sufficiently out of whack that they shouldn't get to make that decision I think that having time-based freeze can also make sure that We as release team give more responsibility to every developer to make his plans and to make sure that he can do the changes he wants within a very well very early known Time frame So I just wanted to respond to some of the comments about this being a one-time thing with the one-year release cycle And and the fact that it is exceptional means that probably we can do some things to smooth that over for For and users I guess I wanted to say you know it is exceptional But we need to make sure that we do take care of it on our side because you know one Busted upgrade is enough for to you know lose an entire institution deciding that they're not gonna run Debian anymore because they couldn't do the upgrade And so they're gonna pick something else Now as as regards doing direct upgrade skipping Multi-arch is gonna be an issue for this So if we're gonna try to support a a direct upgrade path from Lenny to squeeze plus one We need to take into consideration that squeeze plus one is not going to be Installable or upgradeable to using the Lenny package manager anymore because we're going to be changing the syntax of the packages file So it's just something we have to be aware of and if we're gonna do that We're gonna have to provide toolchain back or a package management backports Yeah, I think what Steve just said is very true on the other hand I mean I think people sometimes overestimate the difficulty of skip upgrades. I've Often skip upgraded. Okay, mostly servers I've skip upgraded several machines from such Lenny With really no more difficulty than upgrading etched to Lenny to be honest so and if we can solve the security support situation and Provide people with a slower upgrade path then certainly I think the exercise of trying to do a quick release might be very good for us Regarding the the providing a specific Date for the for the freeze I've mentioned that With I've talked about that with some of the release members, but I would like to know if we will have a date Detailed to the day or if it's going to be around December like like last time so I Expected that question earlier Because of course if you say December 2009 well, which December is it the first December the 15th the 20th Well, currently we are thinking about having a Release day so not a date but a day beforehand but probably We are going to Experiment with the day so Coming up with a day in about one month for this time and see if that works very well or not and So we'll have the freedom to change another to choose another day for the next time You talked about New package formats only be supported in squeeze plus one is this also the case for the source version 3.0 source format or Does it concern multi arc only? Well, the thing is that currently the archive is not ready Some of the build team and have issues with the new format I don't think that That will all be solved before the freeze Or maybe it will be before the freeze, but then we cannot really test it anymore To have it properly done for squeeze So when you said to pick a day not a date, can you explain that a bit more? It's not particularly clear I meant pick a date not a month so not that we not just say December and In December decide what day it will be but that we say About now It will be like the 15th of December What okay? Thanks. I just wanted to follow on briefly to what Ian Jackson said just a little bit ago It's absolutely appropriate for us to make note of the technical hurdles associated with doing things like release skipping, but a lot of the things that I think we think of is Where immediate reaction is oh, that's horrible That would be very difficult for users or something like that aren't really all that terribly difficult And those who've been around long enough will remember that there have been stable releases of Debian already in the past where The upgrade from the previous stable release started out with you need to install this new version of the package management tools from this Special location before you'll be able to proceed with the upgrade that in and of itself is you know a moderately annoying step But it's certainly not a complicated step And it's certainly not the sort of thing any large institution with a bunch of stable machines would have trouble coping with So Let's Simultaneously be very good about making note of things like that that would cause us to need to have those sorts of extra transition steps But simultaneously, let's not feel crippled by that. These are all things that we can overcome so Well if no one else has any Suggestions or comments or questions anymore Well, let's have a coffee break and discuss it in private