 Hefyd, i'n ddiolch i'n gweithio, ond fan hynny'n meddwl yw'n mynd i'w ffordd. Rydw i'n hoffi'n meddwl i'r ddweudio'r ddebconfau, mae'n bod yn gallu'n meddwl o'r llwyllfa gyda'r dros yma ar y smredd iawn. A ffarnio, mae'n meddwl ffarnio'n meddwl i'r llwyllfa. Fe wnaeth i'n gweithio'n meddwl i'r bodai sy'n meddwl i'r bodai hwn. Mae'n meddwl i'r bodai hwnnw i'n meddwl i'r ddaf. The first bit of work that we wanted to do after we'd released is have a retrospective. This was really so we could get the idea of what worked and what didn't. We're certainly not perfect and there's lots of changes that need to be made every release. It is a bit of a iterative process and we wanted to gather the views of what people thought went well. Felly, we went on a sprint over to Belgium, and I do want to say thanks to the sponsors, so we also had Debian there, who paid for the travel and accommodation, and then we had Inuits who paid for the venue itself. Obviously, we gathered quite a number of different points, so we got, after some prodding, quite a few emails in. I do have to say there were quite a few good and bad points in there, and they were remarkably, actually, once we totted them all up, they were about the same, so people thought, people did generally give us things that went well, and things that didn't go well. Firstly, on the sort of good points we had, I think we had a, these were the sort of prime areas that people picked up. Firstly, we had a very high quality release. We managed to produce a release that we really can be proud of, we had the quality that Debian is famous for. An example of this is one user responded, said that their Wi-Fi card worked with Debian, and it didn't work with any other distribution they had tried. And I know that's quite odd given our position on firmware, but it can show that we actually do produce something that is stable, and that has a high level of quality. Another one was the BTS usage, so the tag handling. Developers seem to like the use of the BTS for triaging requests to the release team, and to get an overview of potential removals or states of packages. Third, unblock handling. Generally, although there are, of course, exceptions, people were happy with the amount of time and the flexibility that the release team gave into handling unblock requests. Communications were improved, although there is obviously more to be done in this area. And the length of time between releases was picked up by a number of developers. It was fairly clear that developers were happy with the timeliness of the release itself. And that's not the freeze necessarily, as everyone always wants a shorter freeze, but the actual two-year in between the two releases seemed to go quite well. Next, we have the bad, or the not-so-good point, shall we say? One of the main ones that was brought up here was the communication at DEBCONF9 in Spain around time-based freezes. A lot of people have commented on this before and past, and also the freeze announcements at DEBCONF10. We recognise that we didn't do it as well as we should have. It was a mistake, and hopefully, with some of the ideas and clarities that we're going to have, which we were all about to hear of, this will make it easier for everyone to know what's going on. Freeze duration, yes, everyone doesn't like long freezes. Lack of clarity and process policy, and people didn't really know what sort of reasonable request would be for unblocks. So they did like the way we were very flexible with applying what rules we had, but they didn't like that, they didn't know what the rules were. So hopefully, that will be addressed as well. And one that came up quite a bit from within the team itself, because I also asked them about what we should be doing, is manpower, where we have a limited number of people, and especially around freeze release times, we have a lot of work to do. So that was definitely an issue. And when coming up with a sort of solution for how we're going to do this, that there's sort of a principle that I really want to apply to the release team and release process, which is one based around... Sorry. No surprises. And the idea is that people should simply not be surprised that we're about to freeze. They should not be surprised that their package is about to be removed, or that it's going into testing, or that there's a problem, and that information should be there. And one of the criticisms we've had in the past is our process of removing things from testing. So this is something we're going to try. We're going to create a tool that finds likely candidates for removals for testing, and we're going to use that in a semi-automated way. In fact, very much like we do at the moment, but at the moment we have a list of things and we go manually searching for things to remove, or people come and find us. And one of the important things is that this can be used for the manual removals when we notice there's a problem, and for the automatic ones, and they will mail Debbie and Devel in advance, and say, on this date, this package will be removed for this reason, unless someone comes and tells us why it shouldn't be, or the bug gets fixed, et cetera. So it's very much about providing that transparency so everyone knows where they are and where they stand and what's going to happen in advance. So, again, these are the problems, and I'm going to address them in sort of bottom-up order because that's the easiest to sort of talk about. Firstly, we also want solutions as well as the problems, and so we've been thinking about this. In terms of manpower, there's a number of things. We have the role of the RMS, can be split into sort of dovetailing in general, can be split into sort of dovetailing into what Zach, what Stefano was saying in his talk. We tried it a little bit in the last release, and it worked quite well. So we're going to have sort of two sides to the RMS. You have Adam at the front, who will be certainly leading on the technical side of getting things fixed, making sure the bugs in testing stay there, and I'll be dealing with a lot more the sort of management on the technical side of release management, the administrative side. So it's things like making sure bit smells get out, everyone knows that documentation is there, and sort of the project really knows what we're doing. The second one is sort of a better tracking of distribution of ongoing work. We are looking at tools and various information on how we can enable the project to see what's happening, and we would like to get more involvement or possibly a delegation of people who aren't currently in the release team. We do want to open that up a lot more, because as the number of packages increase, then the amount of work for the release team increases, and it's not getting any bigger, so we need to find some way of reducing that amount of work or getting more people involved. So I'm keen to make sure we try and do that. And the last one is more people. This is certainly always useful. And there has been a couple of changes recently in the release team. We've had to say goodbye, but thank you very much to Pierre, who's been working really hard on the release team, so I do want to take this opportunity to thank him, and a welcome to Neil, who should be around somewhere. There he is, so he's our new release assistant. And Neil has also been volunteered or accepted to do quite a very important job with the above, which is basically to write a lot of documentation. He was asking why there wasn't any documentation on this or on that, and we said it didn't exist. So we suggested that as he goes along this process of finding out how to be a release assistant and working out the policies, that he might want to document it at the same time. And his response was, hmm, now that wasn't no. And if you don't say no clearly, then you end up with this. So for the next couple of years, I think maybe, maybe a little bit less there, then there will be a lot of documentation produced. I'm going to deal with these top three problems because, all together, these are all to do with freezing. And there's been a number of discussions on the mailing lists about how we freeze. So let's have a quick look, and this is sort of how we pick a freeze date in the release team. There's been a number of methods tried in the past, and they all seem to lead to fairly long freezes. Certainly in the case of, in the past, it's been a couple of years, but normally about six months and people find this is too long for various reasons. So firstly, you can pick the number of RC bugs. You can say at this level of RC bugs we will freeze, and it's a fairly interesting metric because sometimes the number of RC bugs never really gets down to that level. The second one is when the RC bug rate flatlines, so you're waiting, so the RC bug rate is coming down, it's coming down, it's coming down, and eventually it sort of reaches a plateau, and it doesn't get any better because there's new RC bugs being introduced at the same rate as old ones being fixed. At that point, it can be a useful point to freeze and to say, okay, now we're going to not introduce any new RC bugs, we're going to keep where we are. And the third possible way we're doing it is when things are ready. So you have KD, or Nome, or the kernel, hopefully they're eventually going to be ready, and we'll be able to freeze that. But that also isn't very satisfactory because the chances of the kernel and KD and Nome all being ready at the same time can be quite interesting. So something that has been suggested on the mailing lists is time-based freezes, and this is the idea that you freeze at a set month and set time and hang the consequences. And the advantage of this is it really helps everyone understand that this is what's going on, so it goes back to this idea of no surprises. Everyone should know exactly the state of the release at all times. And we think it's good. In theory. There are going to be a number of issues, I think, that we're going to have. And these are examples. So will things be ready? The kernel, for example, I see Phil giggling at the back. Ah, right, okay. So will the kernel be ready? Will DI be ready? This is a traditional problem we've had in the past. Excellent. And then what happens if we're not ready? So what happens if it gets to June 2012 and there's 2,000 RC bugs and everything's in a state that influx? So again, solutions. Firstly, reminders. We want to tell the project every month what we're doing and we want to carry on saying, this is what the state is, this is when the freeze is going to happen and we want to really try and get the project involved and make sure that they know exactly what's going on at all times. Secondly, more use of the BTS tags. People like them before, so why not start using them immediately? Why not use them when we're not frozen? And then everyone gets the idea of what's going on. And also people can help contribute as well. So it doesn't just have to be the release team that flags up candidates for removals or transitions and everyone else can help with that. And the third one, described as suck it and see, we're going to try it for release. If it doesn't work, it doesn't work, but we're certainly very happy to try anything. And that does, I do need to just bring on this other point which we've been pestered for quite some time, which is cut or rolling or testing or Bob or whatever it happens to be called this week. This idea that there should be something different to testing. I first want to just have a look at what testing is for. Now originally when AJ set it up, I think we managed to dig through and find the original males and the idea is that it just should exist to make stable releases easier. It should be a tool of the release team and nothing else matters. Now obviously we've moved on slightly from that. We're not in that position. We have users and it is in itself a very useful tool. It's a great way of providing testing for the stable release of having an area that is not unstable and has some sort of level of stability there but isn't a full stable release and people do like that. Now there is a question of can this be unbroken at all times and not easily possible is the answer. There are times when the release team will break testing. An example of this is when the Perl 5.12 transition got tied into the EG Lib C transition which created thousands and thousands of packages that all had to go migrating testing first. What we did is we broke Lib SVN but only on K3BSD and that allowed this transition to all go through and we forced it through. It's important to say that when we break something in testing we clean it up afterwards. It's not something that we just break it and then leave it and then there's a horrible thing. Whenever we use a force hint and we force things through intertesting we make sure that we track the state and we know what's going on because we really do care about testing because it's the next table release but perhaps the emphasis is slightly different on how we care about testing. It has been mentioned that we could use cut or rolling and basically our position is there. We don't mind. If people want to put the work in, excellent. That's fine by us. We shouldn't impact the stable release process. For us in the release team our perspective is this is what we as a project are trying to do and we're trying to get a stable release out. If it essentially doesn't mean more work for the release team then that's absolutely fine. This includes asking the release team to do some work. There's some values of work. Of course we're always happy to answer questions and give support to anyone who wants but getting the release team to do vast swathes of work is something that as much as we'd like to we just don't have the time for. There's not that many people in the release team and I should point out if you are interested in coming along and being a member of the release team we'd be happy to have you. The idea behind rolling came about because there was a feeling that during freezes there wasn't enough development and there wasn't enough sort of excitement new development happening and the entire project started focusing. Now instead of essentially releasing a new reboot strapping a new suite and doing things a whole new way we'd like to take something that's a little bit easier more straightforward and can be accomplished in a lot smaller time frames. This idea is basically experimental should be easier and it should be easier to develop with and there's a couple of things we've got coming up the automatic moving of packages from experimental to unstable thanks to our FTP masters here. We've asked that there is some sort of tool or a suite that allows you to say okay I've uploaded my packages to experimental and they're tested and everyone's happy now now perform this action which moves all of that into unstable avoids unnecessary rebuilds and so it doesn't hit the building network and it's just a very easy way of saying that should now go in experimental so you don't have to re-upload and then wait for a de-install and then wait for all the rebuilds to happen and then have a look at that you can just very easily use experimental and the second one is on-demand experimental repositories this is slightly longer term goal I think Mark said the first one he can do within a week or so but the second one is going to be slightly longer and this is the idea that you can have your own experimental bit like a sort of PPA if you want to say start to work on a transition or work on a large change you can get your own experimental area that you can have and that disappears once you're done with it and this idea so you can work on anything you want even when unstable is frozen and then we have to look at the sort of second reason that experimental isn't used as much it needs to be easier to use so easier to explore people should be able to see what's in experimental they should be able to very easily pick things out and again we have this second idea which is the experimental changes mailing list we currently have testing changes so people can subscribe to it and see what new things are coming into experimental and really try and help to raise the profile of its use but there's also a bit of a question mark one thing I don't know obviously why people don't use experimental otherwise we would have fixed it a long time ago so really obviously welcome any ideas on how we can improve that and there's always ideas about how we make unstable and how it's usable during freeze times and inserting different levels of sweets and my view is that there's always been one we've had the experimental suite it's always existed, people should use it but I'm very interested in finding out why people don't use it I've deliberately left this quite short so we've got about 25 odd minutes for questions and I really do want to hear people's thoughts on what we're doing with release what sort of principles we should and how we can do things like make experimental more exciting so I guess I'll hand it over to the floor if anyone has any questions so can you hear me? try that should be working does it work, does it work? does it work? so one question or suggestion about the transparency of no surprises thing it would be cool if for example popularity content or some package like that if you have some set of packages installed in your current stable and the new stable is coming soon so you get notifications if any of that packages are going to be removed so for example you depend on some package which is in current stable but will be removed in the next so you get some notification I don't know it returns output your cron job or something so you can get notified and maybe you can then act something look at the bug maybe fix it suggest something or whatever yeah certainly when we're looking at the how we're going to do removals from testing we can probably do something machine readable as well as normal so people can have a look and examine what they've got and see if they've got that package installed that certainly shouldn't be a problem I think that was I think I heard you just there volunteering to write it as well wasn't that that will certainly be useful and again it's about adding work to the reason we do want to do things that make things easier for us and for the project as a whole so it's certainly something I think would be useful Any more questions? So comment on why don't I use experimental more and so this is either a technical problem with me or with the build demons is that picking up dependencies from experimental so if you have a package you want to put an experimental but it depends on some libraries and those are an experimental that doesn't seem to work unless you have version dependencies on the libraries which you don't necessarily want to do in general just to make the experimental build so that's maybe a minor technical issue or maybe I need a clue but that's in my experiences then it's been troublesome to get things to complex things to build an experimental I think we've probably got some build people or FTP masters around here that should be able to to talk about that I've got a spare microphone we can get at the front here or actually here's one Is this on? So actually what you can do for so what you can actually do now on the vulnerable side is do temporary dependencies or build dependencies for packages that I actually added during the build so you don't have to get everything right in theory but at least for binanim use into experimental you could specify that it should pick something else from experimental to make it easier but that hasn't been communicated in a good way yet but it will hopefully be soon there's a lot of this is going to be useful documentation which I'm sure will be produced any day now looking hopefully towards the back so that's certainly something we can hope if you look to your left at the person sat there then he'll tell you exactly how to do this I'm sure that's absolutely fine at the front I think for myself I'm a lot more interested in having some kind of set of archives that I can use rather than just experimental the menus of experimental that I make is building versions from upstream trunk of some important package or other and those are typically not directly suitable for promotion to unstable but I might also like to try out something that will be useful for promotion to unstable so I'm a lot more interested in the I realize more difficult larger piece it's certainly more difficult for the FTP masters it's fairly straightforward for us I believe because we don't need to worry about it I want to know how you made your slides because I find them amazing this one is a website called Prezi.com it's not free software and if anyone wants and I was tempted to start a boff on why free software doesn't work for UK government but that's probably another question as a hint it was very much hindered by Oracle's purchase of sun and what that did to the rate of development of open office and I see Tom raising his hand there I'm not sure in defence or in attack of this proposal it's actually not a comment on open office or Libra office at all but one can make a presentation like this with free software with a tool called Jesse Inc which is basically on top of Inkscape and so you could have the same effect it's really quite fun it's J-E-S-S-Y-I-N-K I believe I'll send an email with it like that would be easier you need a pretty good CPU to do that with SVG it's SVG so you zoom in and zoom out but that's a lot of fun there's a question about it is it accessible as well and I don't know but that is an excellent issue for us I think to always think about accessibility so the question was do we have any update on when we should expect a Lenny point release I assume Steve is asking because he's trying to plan his thing I think the 10th of September might be a good weekend I point out because that's when Steve is getting married so I think along with Joe his lovely fiance so I think if we make sure that in between the vows he just types a quick make CD release and pushes that out I'm not sure I'll be the most popular person at the wedding but that should certainly be any idea from our SRMs at the front when we have an X point release nope, they're shaking their heads so I think the answer to your question is no it's on the to-do list while I'm on that what we had is the etch-a-half in previous years and we are looking at not necessarily doing another one because if we have I think a fairly two-year sort of lifespan then that's a lot shorter than it has in the past but we are looking at our policies on what we do with things like graphics drivers network updates things to support new hardware and what we're going to do around supporting those in Stable because I am keen to try to make sure that Stable remains usable for as long as it can do Well, as far as I understood Ben asked for testing for network drivers to the next stable kernel he backported some of the network drivers and probably and as far as I saw it got no response from anyone to that so there is some backporting of network drivers to the current stable kernel Someone at the back Yeah, so I think there is going to be a bit of a change to how we've traditionally done things this is the a great talk which Joey Hess was thinking about called the Balkanisation of Debian and this is the idea that the bulk the impression of the Balkans has been in the past not great and that's changing a lot so there is a lot of great things happening here and it isn't a war-torn country it's really quite quite beautiful and there is the impression of Debian that we have flame wars all the time on the mailing lists and that stable releases are old and out of date and we do need to change that we don't have huge apart from system D huge flame wars on the mailing lists anymore if we have a look at the amount of GRs that we have that's really gone down quite a lot if we have a look at the last DPL election there was one candidate so we don't have this very divisive thing that we used to and stable releases are coming out now every two years fairly regularly and we also want to try and challenge the way that people say stable releases are old and out of date returning to the question of updated hyperdrivers the previous point update already had back-ported drivers for the E1000E and the brocade driver and some HP storage stuff but there are still free back-ports from network drivers which need testers if any one of you has one of these updated hardware it's documented in box against the kernel package all the testing stuff you need to do when you run this and once you report back to test results this can be added to the next 603 point update so these are things that are already happening we are already seeing new hardware being supported in stable releases I think someone next to you was it yeah if you would like to make a call to test newer kernel drivers or whatever just ask the publicity team and we can then or mention it in the dbn project news and a question at the front I think we had do you have made any plans to support the new kernel versioning for stable so that one can use newer kernels I think within our current stable release obviously I'm not the state I'm not involved with the stable releases that's Adam at the front who I'm going to pick on or Phil who is studiously ignoring the microphone that's being offered to him very well so so is there plans to introduce new kernels basically or use concurrent versioning so we can have within stable releases or support that as far as I know there aren't any plans to do that except from like suggesting that there are kernels in backboards and maybe fixing up stuff in stable so that you can actually boot with like 3.0 kernels so there is some that we can look at there yep then we want to have any else they want to raise I was just wondering the timing of the proposed release seems kind of right maybe before debcom for something like what was the plan for why June 2012 well firstly that's the timing for the proposed freeze rather than the proposed release we do still want to stick with releasing it when it's ready because that is a very important thing it's almost what Debian is famous for we release when it's ready not from any particular date on coming up with the perhaps Adam may be able to to chip in as well but on coming up with the date for when we freeze the month it took me 2 or 3 hours or something or discussions to try and work out this date and we realise it's not a perfect date for everyone if we have it before debcom then obviously we're frozen during debcom if we have it in afterwards then we're hitting school holidays or we're hitting Christmas or some things just won't work so we basically picked a date we thought was going to be reasonable and we hoped would aim towards the about 2 years between releases that we were after and so hopefully we can then release slightly quicker than the 2 years but if not then we do have a little bit of time extra there and it's something that we could try one of the issues we had that the project had with the previous proposal was how that syncs up with Ubuntu and one of the views is that we were doing this to simply help Ubuntu having talked to Steve Langersack I'm very very assured that this does not help Ubuntu in any way shape or form he was very very clear that this is not a good date but that said in the future if this does work and we want to again pick if this does work very well then I'll be looking at doing something like June 2014 for the next release and trying to regularise that so again everyone knows and then other distributions can try and sync up with that again if it doesn't work in June then we can try and change it but it's very much about making sure that everyone knows what's going on at all times the front so if somebody were so full hearty as to respond to your call for more manpower on the team what would what would you be looking for for them to do and what would they be getting themselves into in terms of a new member of the team yeah Niels is saying quite documentation there now that Niels is on the team already we've already got a volunteer for that so we don't need much there the best thing to do is join the Debian release mailing list if you don't already read that try and find things called easy hints sets of packages that depend on each other that they have to go in hopefully that will be a slight easier problem in the future we have something called Brittany 2 coming along which is the tool that moves things from unstable into testing and that has some auto hinting capabilities that tries to work out packages that can go together and we also have a SAT solver which we hope to use to again provide for some of the slightly harder easy hints easy hints are basically where we say that package and that package needs to go together rather than preferring something over another one so some of those harder situations hopefully the SAT solver can help with but there's certainly a lot of stuff again documentation is very useful if you come and find something like that and say I don't know how that works then ask us but then write it down one of the things I did in my last bits mail was I said we need more documentation and what do people want do people want FAQs do they need glossaries of the terms we're using do they want flow charts please tell us and I got zero responses so nobody fed back to feedback at release.debian.org as to what they want what sort of documentation do people find useful sort of an open question to the room and I'm getting the same level of responses as I did to my mail I see so people put their hand up if they think documentation about the release process would be useful right so some people think that would be useful so Neil just put his hand up as well so that's probably very useful as well as he'll be writing most of it it's something we're keen to do to make sure that everyone knows what's going on so writing documentation although it could be not the most exciting thing in the world and it's something that's always useful to everyone anyone else on at the front I'm very excited by the idea of having a special experimental repository for preparing transitions but as you said it's not your business mainly FTP master but it's not only FTP master there's also a problem of build damage integration much more than just FTP master do we have some sort of coordinated plan already or is it only a one or two FTP master thinking allowed a hoe is that really nice it's not directly for you but maybe Mark can already answer there is an email about to go to the build people before we send it out more publicly so yes we're working on a plan but we haven't finished it off yet so there is a proposal and I'm just being cautious because Phil's only sat slightly to my left and he doesn't know about it yet but yes there's an email going to build D fairly soon to talk to them about what would be necessary and then we'll send another project for more comments as a whole and I'll also point out at Thursday at 10 apparently there's an FTP master boff so if you're interested in anything to do FTP master or DAC going on Thursday at 10 Thursday at 10 10 o'clock on Thursday there's a boff yeah it's Thursday 10 o'clock just in case anyone wasn't clear as to what we've got there so you've got anyone have any again sorry just leave them with the microphones they'll have a bit of a chat between themselves for a bit I'm worried about cut and rallying and stuff you told it's fine if you're if we're not blocking you not making it harder to make stable release but let's say that I tell everybody that testing is usable and that they should use it would that make your job harder or not well we always want more people to use testing it's a bit hard to answer that with a yes or no question people finding bugs in testing is useful because we want a good stable release we're not going to guarantee though that testing will always remain unbroken for all packages because there are as I've shown there are reasons that sometimes we just need to break it there are no other ways of getting these packages migrated with our current tools but that said we can't try and keep it as usable as we can and then when we do break it we always make sure we clean that up afterwards and when we treat it very carefully second question on this topic I saw what you're making to keep it usable breaking it on K3BSD is fine I think K3BSD users might not agree with that temporary people who are using K3BSD currently use seed anyway either stable or seed I don't think there are many test we really need testing because they're not clueful enough to fix stuff so I mean when we're looking at keeping testing usable at least for the rolling idea is really for the main stream of people that is mainly I386 and AMD64 and my question was just would you mind if we to add a rolling sibling to testing just to be able to use this marketing effect to say testing is not broken so we can call it rolling I understand that I'm not sure that creating a new suite and everything around it is perhaps the best way of getting a marketing effect to try and say you can use testing I personally don't particularly care what it's called I'm not I don't really mind I like publicity people to think if it's particularly better if it's called rolling or testing or whatever we do the problem with potentially calling it rolling is what happens in freeze time does it stop rolling so I think testing is a useful description for what it is we have run out of time but thank you very much for everyone and if anyone has any questions then certainly myself and Adam or any of the release team I'm sure would be very happy to help answer those thank you very much everyone