 So welcome welcome all to my talk about the release process. That's the perspective of such such was the last stable release is the current is the stable release And my name is Anzejas Bart. I come from Munich in Germany And I'm a member of the release teams the release team consists of five persons that are Steve and Colin as the leaders instead of Frank Troy has and me as assistants and yes, but And in the team you work very well Everyone has has its tasks and you don't really see the difference But you all have a common goal that is to release or is that what was really such it's now to release edge and time But I will tell about that later on in this talk. So welcome you all So the reason Debian the first question is why do we do it? There's a very good reason our users. They want a stable basis that they can work on so you can deploy their work on They can install computers, especially if they administer it more than one system They often dislike to have a packet one package update today the next tomorrow But they want just to restrict how much administrative works you need to put into For that reason Debian publishes stable releases and we did literally publish them when they are ready So I was there that yes, we are now, but it takes sometimes a bit longer than we originally had hoped So the stable releases we had already are from bus that in June 1996 to the search which was in June 2005 before bus ever another way of releasing Debian But that was I would say the old kind of releasing and who's interested in that should read the package Debian history by B Dale So such now the current stable release consists of over 8,000 source packages and over 15,000 binary packages And from the sheer amount you can see if you want to release at all We need a lot of coordination to make that possible and that's the task of the release team basically So what does Debian consist as distributions? We have four to five this so-called distributions inside of Debian says sometimes like now on all stable It's a stable that's a current release distribution says testing or the well expected new stable sometimes later unstable and experimental That's currently all stable is woody stable as such and testing the next table candidate is edge and For the developers so you should upload the packages just into unstable From there they go to testing if they are there for a certain time and if no problems occurred and If if we are satisfied with the testing in whole that means not only with the packages But with everything we make a release and declared a stable and So old as a thing that was stable for us and the name to all stable But I want to say something about these things. I just say how it works in general There are some exceptions that are better documented in for example the developer's reference But I don't think that you I think you're more interested in the general overview How do we do it and not in some picky details about what can go wrong in this for example testing migration of packages So that's who's interested in that should perhaps come to my other talk for the developers So what does a what are the least standards? Package must not have critical or grieve bugs That means just it must not be unusable the package or the system or they must not be security bugs The package must be also okay from the maintenance point of view the package needs to be free of course We are speaking about free software. So package must must be free. So we must be able to make some security support for the package Then to call the release policy with a lot of smaller issues that are more technical Of course a package needs to be follow them. That's now the link for the next release policy The current one for us for such has of course such as the policy So this dollar needs to be ready for a release. We have some release goals that need to be met so that's more or less what we have to achieve and What did we achieve for such or what are our improvements from the user point of view? That's of course definitely see very good installer. I would say one of the best or the best installer currently on the market in a very far Better than much other a lot of other installers. Of course the usual I would say a lot of better improved packages Debian improved a lot between Woody and Sarge But I guess about these things and a lot of more things of the user view Improved things in Sarge. There are other talks here. So I better speak. What is was improved? Release management wise technical advice our infrastructure has very much improved that's installers. It's easier to cope with Bootflop is what's the old installer everywhere. The colonel has improved very much for for Woody we had 11 different colonel source packages, which is very An interesting challenge to make a security update to them to put it mildly now We have three different source packages one for two two one two two four and one two two six So I think that's it's can get a bit better like we can stop server to two package Definitely different next time. We can perhaps even reduce the number of to four packages or so We also improved for with the release team tools And when I started to take a deeper look at the at the release team that was Beginning of 2004 as it means a bit more than about a year ago They have a not many management tools So the least you could say okay We want to put a package into or the least manager could say I put a package into testing despite all the things that are not fulfilled Now we have a web we have more five finer tools. I can say this package should go in even if it's too young But that doesn't mean that Bucks that's critical bucks would be ignored So we are improving our tools there and that makes it easier for us to manage the least release We have a better bug management function functionality I can get a buck list of say what are the bugs that really block our release But and I'm only interested in the box that all does in a week because we know most of these critical bugs are Solved in a week by the maintainer and we as a leasing don't need to care about them Of course, we need to care before I say, okay, this is now stable But we don't need to care on about them on a daily basis We have a better security issues I think that's mostly joy has to work Which helped us very very much to know where are we currently so that we know how long is the way till the release but of course Okay, so What is as a managing a release they're not only the packages says more And our part as the least team is to make sure that also the least critical issues So I extended by it for the release and that involves a lot of things that are well Not so visible. For example, we had a problem this time So do you want to publish CD images at the day where we release which is of course a good idea I think basically but we had the problem that we had too much too less hard disk space at the publishing the CD images Such a small issue that of course it was solved quite fast But there are a lot of small issues we must make sure that we've forgotten none of them because otherwise we might be a bit spoiled of if you try to really to release and some thing fails And of course the next is if we make any change to the current testing We must make sure that this change will not put us push us back again That's if I write it down in this way everybody will say, okay, of course That's a right target, but it's a bit difficult to argue that to maintain this If you have a very good idea how they could get their package fast into testing So so the least team has also said the great task to say no way too often But that's part of our of our task and I can live with it The next one is that we really we need to search for the release blockers and tackle them Best is of course if you find somebody to tackle them But in worst case we do it ourselves Then we have to communicate with all the other relevant teams because the release team just holds Yeah, the most important things that we can do is speak with other people. We cannot Directly do so much. So we have to speak with other teams What is their opinion what to see a second side as blockers is that something in the toolchain? For example the broken that needs to be fixed just to name something that has Was very ugly sometimes Yeah, and let's end in the end. There are also a lot of tiny issues like there's a broken packages needs to be removed from testing There's unpackages that need to be looked into by the don't go into testing by themself Such things happen Well, but that's easy to the last one is the easiest one to in the from the management point of view so what We have achieved a lot of improvements for such the question is what do we want for edge? We want to have first improvements. We we saw We saw some issues some parts that we can get better than we are so we want that of course We can improve the bug checking tools because currently a bug is marked as close It's the moment I fix it upload to unstable, but our users don't care for really fun It's the end. It's important to fix this in testing this For that the call is already written and it's about to be deployed any day now And the next one is we need to improve the house a package goes to testing and Interacts with stepping as dollar packages There is some handhold needed as of today and handholder always to disadvantages the one is there needs to be somebody who spends time on it That's always bad because we all have to feel to less time especially for things that needs to happen on a quite often in the second one is As long as human people do something it's easier to just overlook something so if you can write a program for it and we say okay, this This makes sure that everything that we want to have is satisfied We should go that way. There are ideas. I hope that we can deploy them soon The next thing is The ways the kernel packages interact with the installer has improved very very much from Woody But still is there some way to go to make it even better. I hope we do it It's the last one what we really want to do and I'm quite Yeah optimist that we do is is you want to release on a time-based schedule this time We say you want to release in December 2006. I'm quite sure we will and For that reason we reduced the number of release blockers As the least team to wear a few issues. They're only like four issues and three of them are technical so That's Yeah, not too hard. I think not too many and the most other things that we oh, I would really like to see it in it So that just take the least goals. I hope they will be several made it if it's only one or two packages Hold it up. Perhaps they might become even a release blocker later, but for now They are only released goals so that we don't Miss that timeline Yeah, so I'm quite optimistic we make a system in that way So that was now most about I think the release process So we have still some time left for questions from you and yeah, welcome to that So I ignore now the debt debt and project leader any other question Okay, so Technical and I wanted what that was if you say something about that Okay, so now I really need to reconcile that what it was because I don't I don't know for my memory currently Okay, we have we have to change the tool chain That's just as it happens the tool chain means the compiler see libraries are some change and this new version of the compiler That's already happening as of now says xorg happening sales Mirror split and And the addition of AMD 64 architecture We have we have the dog in dog in main situation So Okay, the tool share would say is fully technical So xorg is I would say definitely a user a user wish but also a bit technical The dog in main is just a well a conclusion of We as a release team don't didn't had any any opinion on it because we just have to do it It's not technical yes, so well But in my opinion most of the more of the things Technical things that are about to happen and six xorg transition for example just happens as of now more or less so So there's nothing that I really would say it's Actually, I just hope I just hope and that you won't say no now, so you would have agreed to you in front of public It's it's most is this working okay, it's mostly in David Nussin now's hands, so so I can't speak for him, but I An idea that I that had been bouncing around in my head lately That would seem to dovetail pretty nicely with this was I have fond memories of several years ago when VA Linux did their slink and a half release and because we might want to Have some trial runs of Release processes. I was wondering if there were a way we could do preview releases You know say just to throw out a couple of dates at random Sergeant a third in December of this year and then sergeant two-thirds and June or July of next year to to to give a to give a kind of a trial run of The automated release process, you know making sure that there's room for the CD images and the other things we would overlook And and to you get some real testing of the further infrastructural improvements that we'll be seeing and the the point of this would be What will the benefits of this would be not just that we would get some testing of these pieces of infrastructure of a more automated release process, but that it might provide a way to Address the concern of our user community that 18 months is too long to wait for a release I know for my work with progeny that this is a very long question, isn't it? Yeah, I don't consider the question the color for that Yeah, it's an idea and I just put it out for some brainstorming and consideration for my work with progeny that enterprise users are They push very hard for long, but predictable release cycles Whereas the desktop community, of course, they want things to happen more quickly So I was just wondering what your thoughts were on that Is it complete? Bullshit should we just not do it at all? Okay, so there are actually two to three questions So please let me separate them. So the wrong way. So the wrong question is can we have a better Preview of what happens at a stable release with our release procedures And there's something to say a stable release didn't happen as often until now So I think about six times till now Obviously current who's that even only about three times till now so that we don't have as much experience as we perhaps wanted There's something we definitely learn from this year at least in my opinion Well, I just say it's still discussion going on. So I can't speak and say so the least team has the opinion that I'm speaking What I consider currently is a interesting way to go as a good way to go But discussion will show if this is the way to go on another way But one part or one idea in the discussion was to say, okay, actually we do the release on some date We just push it to some hidden mirrors We built the images on these mirrors and our core team of coail are consisting of 10 to 20 people Tested really everything after that. It means they take the CDs that are hidden in stores Only if that works we say, okay, it's the least that would mean for some of course some of the Developers won't be too happy with that because it means there will be no de-installed on for about a week But I can think we can live with it But that's just one of the discussion ways that we can be sure that we how do we release and if we release really everything Works and the only way I think we can do is if you really check it and checking means We do the we do the technical speaking so the least we don't show to all of our mirrors But only to one or two is that selected people have access to we check it and everything works. We publish it That would be the way to go because a break is just have shown this time We're not on the package basis level packages were all back to file, but there are things like So this time the images were built before before the release actually happened from the content of files So the city which has picked up a wrong release file and made a mistake in the security thing We learned from that definitely There's more than one thing we learned from it we learned also something else because Surveys this empty was composed was perhaps not the best way to do it So we had two issues and if it was one of them it would work. We will solve even both of them Yeah Something there's something else. It's a moment. What you say is well, I I definitely disagree with saying we have some testing as that of some date and push that and keep that separate on the mirrors Because in the moment we do it because it's stable So if you can do it, we do it and we call it stable. So the question and the question is just For all of our packages are concerned. I think we were very successful with this time We will we started to slow down the blockers of packages from unstable into testing and we slowed it even further down And in my opinion it worked very well with exactly one exception That was that we were not able to success so successful It's like all the bugs a certain answer but not in testing and that we are going to change as I said before That's one of the process improve when we need for edge So I was in that way. How we dealt with packages. I was really happy this time It worked way better than I had expected frankly speaking So that's something that really worked and if something worked. I don't see a reason to change it So what didn't work was the final bits like changing the content of the release file on FTP master and that's just needs to be to be detected and if I and if you have seen the I would say crazy son people's right on on I may a bit before that was not the best perhaps yes, I think we're getting a bit deep into the technicalities of this We could probably come back to this at your It's all right Just let me say once and the second question. All right The second question was how is it for our users that want shorter release cycles what we are currently aiming at a bit At least is what our choice is aiming at is to make sure that all the testing Where really fulfills the least criterias most time the testing has a quite fast fix of Security bugs and if companies are interested to be really up to the speed Then it might be in destined to run testing I won't recommend to run testing as of today to companies But I hope that we can get to that in about half a year time one year time about that We can get more out of testing than we do definitely okay Just getting back to Brandon's initial comment that you like the slink and a half that came from VL in expect then Comparing back then and what we have now. I think that in a sense We could say that the Ubuntu releases are those and a half or in the third release in a sense that a lot of the Direct testing that has been needed for instance for Xorg for GCC for transition and for a lot of other things have already been Tried and proven and debugged at least partially and in some case totally at the Ubuntu front when Hori released So that by the time edge comes I'd say about 80% of the problems have already been dealt by with at the Ubuntu level because of their ability to move a bit faster Since their package base is a bit smaller than us. So so to me. I mean I Think we've realized your Slink and a half goal in the sense that Ubuntu releases every six months. They do those kind of rapid transition they Do a lot of the raw work that is needed for us to be able to Follow up more quickly turn over more quickly with release. So I think an achievable goal would be For Ubuntu to keep on releasing every six months and then they be in every year or every year and a half Then we would have the desired effect and of course During warty time the collaboration with between Ubuntu and DB and perhaps wasn't ideal But now since Hori it's improved dramatically. So I think we can achieve it that way. It's just a suggestion. Okay Okay one thing is What my opinion was not so hard part was not how can we do the transition but that a lot of people wanted to push their pet whatever into into into search right now and that delayed and That's one of the basic decisions that we as the least he made. So to say we don't of course We know all know how is this pet issues? We have I have said myself some pet issues So but we said it might be pet issues, but I said we can say We release or we can just it's not manageable. So we cut the pet release issues Pet release goals to really say is that a pet goals? It's nice if we meet them if not We could really listen any case But now if another is a question just to you all because actually in my opinion I Well, I was here with their expectation to speak with also with non developers So if they're not developers questions, I would be happy to answer some of them I can believe really free because that you don't get to this technical level Perhaps better to not speak as technical as now fairly simple question you mentioned the four release goals for edge and They do not seem to fill up 18 months. Can you explain why it takes 18 months to fulfill this for? Release goals. Okay. So I think the question is up. Is up Yeah, it's it's a bit different Because actually we said, okay, so they've been developers want to To work on a lot of issues and it's not as we say as soon as all the four goals are Release targets are met the release, but we say, okay, we have Certain as some patient for release for example as you said Centre by users push for large and particular cycles for very good reason our developers want some time to Work on new things as there happens a lot of the development inside of Debian And not only oh, we just import some new upstream source and release But that happens active development So we need some time for it and we notice that with the last last release we frozen tools chain tool chain in August last year Because we expect that that might be a bit faster and then we noticed that this was a bit bad for development of the tool chain So we want to have some development cycle open and in our opinion as the least team So the normal development cycle is open for about a year of normal development before we start on freezing That does not mean that we forget now about testing. We will keep track of testing if something is broken Is there we will try to push people to fix it now? But I think it's a good thing to have also normal development cycle. We're not only oh, we will release about tomorrow Okay, I think sorry one last question and then we'll move on to the last Last question and this is the most important question you will ever hear at this conference But this is vitally important for the future of Debian will the next version be 3.2 or 4.0 Basically, I don't know But let me just say something about the most important question as ever question is the most important also ever packages We have at the least team. We have very good exit. We know how to deal with such things but actually actually we don't know but I Basically if we would have decided about the least number of such let's say four months ago Probably we would have gone for a new major release number But at that time it was already fixed up in a lot in so many places We said better to have to go with 3.1 then this 4.0 at most places and some will still be 3.1 Okay. Thank you very much on this