 So this will be the Debian rolling buff by Rafael Herzog. Good morning. Thank you. Enjoy. So, it's going to be a buff, so I have a few introductory slides to remember the general topic, and a few set of questions so that you can start the discussion. It's really specific on the rolling part. Again, we have the CAD project, which is more encompassing, but this is really the rolling, so testing distribution that is usable. Well, my goal, this is my definition of rolling. It's distribution that is always usable by end user, but which is not stable because it should have regular new upstream version. I believe it should target mainly the desktop market because, well, that's the kind of user who are really keen on testing the new upstream release and who can afford the occasional hiccups that it implies. The consequences are that, well, desktop users are mainly on the E386 and IMD64 architectures, so for the usable part, we should mainly care about those architectures. So, all of them are nice to have, but not really required for rolling. Of course, constantly usable means that maintainers should care about their package in rolling, so that's why I seek some sort of official support by Debian to give some weight to the constantly usable part. Well, targeting the desktop market obviously means not targeting the server market because, well, I think everybody would agree that the server market is well served by our stable release. So, with my definition of rolling, I mean why not call it testing is really close to rolling, testing is regularly updated, but is it really always usable? Well, if you speak with people, yes, mainly. Most, well, we have many feedback from people who are using testing daily and we try quite happy with it. But if you read the recent thread on Debian Devil, there are at least some people who are saying no to this question. And I come back on the next slide on the details, the reason why the answer no. Can we afford to support users on testing? Because, well, they're not always official support either for tests for security or even the usable part. Sometimes the release manager breaks stuff in testing. And we have few maintainers who don't care really about testing because, well, it's just a place which is used to prepare the next table. It doesn't matter if something is broken until the freeze because, well, they believe they have enough time during the freeze to fix whatever is needed. Well, we have, for example, Roland Maas mentioned once that the Fusion Forge, well, it's quite a special package in Debian, but it involves many other packages and it's difficult to get its table when all the other parts are moving around with new upstream version and given it's mostly alone doing the work. Investors require time only when the world is changing during the freeze. My opinion is that supporting our packages and testing should be a duty of all maintainers. And it's a cultural shift that we should embrace. It's something that's already happening naturally because while testing is a place where we are fixing our packages so that they are perfect for the next release, but we should still reaffirm it and go a bit further because we don't want to fix them only before the next release but in a regular manner. I mean, as soon as problems come up, they should be regularly fixed. It's all a problem of manpower. And also it's the best way for us to actually build a solid stable release. And all the release manager would agree that getting rid of release critical bugs and annoying bugs in testing as soon as possible is best and not have to wait until we freeze. So what makes testing not really usable? One of the common comments is the lack of a good installer. I mean, we don't have any official way to install testing directly. In truth, there are many ways to work around this. We can use the stable installer and this upgrade or you can use almost any version of the installer in expert mode and pick up the target distribution. But it's not... Well, expert mode is not really what we want to advertise to our rolling users. All daily builds of the installer and install testing by default and all the CDs through testing. Okay, so maybe we can simply grab a copy that we know that works and keep it. Another concern that has been raised is that some bugs in testing last for too long because, well, when you have a big transition, sometimes the bug fixes can take a lot of time. So that's why Jocelyn Mouet suggested to have a sort of overlay repository where we can grab or cherry pick updates from seed and make them available to testing users. In theory, it's nice, but the main concern I have is that if we can do that in a overlay repository, why not do it in testing itself? There could be cases where the migration is not possible due to problem on alternative architectures where it would make sense. But in practice, I'm not sure it's happened that often. Excuse me, doesn't that happen already? Because high priority fixes get propagated to testing in the course of a few days? Yes, but if you have a new version of a dependency which is going to create a transition, until the transition is ready to migrate the whole together, your package won't migrate. But that's the kind of problem that... You can change that in a loading repository. The repository won't work. Well, the idea is in this case to sort of move the transition sooner in the overlay repository. Well, there are problems with this approach, as I mentioned. Well, it's sort of the least contentious proposal that they've been suggested and developed in the last discussion. Well, I'll just finish the rest of the slide and then we'll jump in the discussion, really. The third problem is that some packages are dropped for different reasons. Sometimes for transition, like the example that Neil gave before in the Deben release talk. But usually it's only on a specific architecture, usually not a mainstream one, and it's really not problematic for rolling, I believe. The most problematic case is when we have a package that we can't afford to support on a long-term basis. We had the cases with Chromium, which had been sort of fixed, but it's still not very clear how we're going to support it on the long-term. But in those cases, we tend to drop packages from testing because they can't be supported in stable. But they are supportable in a rolling distribution just by uploading new upstream version on a constant basis. Well, just to have an idea of the audience, I would like you to raise your hand. I have a few questions for you and you have to raise your hand to answer. I'll just explain what I mean by the question before. First one is, do you believe that testing is usable? Or another way to put it would be, do you think that there are users that would be well-served by testing? That means that they're not well-served either by stable or by unstable. Second question is, do you believe that we should use a job testing or should we officially advertise testing as something that should be used by end users? And the end users that you have identified in question one, of course. And do you believe that we can support user testing? Do we have the required means, human, technical, etc. to provide a good experience to those new testing users? And if we don't, is it something that we can easily or with a reasonable effort? Is it something we can achieve with a reasonable effort? So who believes that testing is usable? Raise your hand, please. Who believes that testing is not usable? Okay, I know it's broad. That's why I gave a sort of meta-explanation first. It's easy. Okay, do you believe that we should endorse usage of testing? Should we advertise it more? Okay, a bit more mixed. Who believes that we should not endorse it? A microphone, please. If the goal is to say, please use testing so that you can do the reports and help us, that's great. But if it's to say, please use testing for your everyday life, I don't think it's a good idea. Actually, I think it's both. Because I find bugs when I use it for my daily life, so there's no difference between both. And third question, do you believe that we can support usage of testing? Please answer. Or do you believe... So, do you believe that testing is not... That we can't afford to support testing? Okay, not few. But many don't know in this question what to answer. Yeah, okay. I asked the same question to the current release team. I got only four answers out of 12 persons who have been asked. Everybody said yes to the first question and to the third question. They were mixed. The positive version of the question. Yes, the positive version. So, already the manager believes that testing is mostly usable and that we can support it as it is. They are mixed on the idea of endorsing it more officially than no. So, that's why I asked the question to Neil before. Is it fine or not if we say loudly that testing is usable and we welcome users to use it? So, at least the release team seems to be in agreement with the dev and body, which is nice to see. Perhaps I could add one looping. I have friends who use Linux distributions in general and they say that stable is too old always and unstable is too unstable. But they don't consider testing. So, they say to them use testing instead. So, they have that testing as an option. They think that unstable is too broken and stable is too old. So, why not tell them to use testing? Yeah, I agree that we should. I mean, I'm convinced of this. That's why we're discussing here, how to achieve this without creating big frameworks. Okay. I believe that this community of testing users already exists and I know that because when my desktop packages, which aren't so many, but when they migrate to testing, I see a bump of bug reports and they're not bad bug reports, but I can tell the difference between bug reports from SID users and from testing users. No, I'm serious, they're not bad, but they have different expectations. So, little word on stuff that has been done, not so much. There's this repository of Jocelyn Mwet, which is supposed to be an overlay on testing. He has working code to generate it. Unfortunately, we are almost unable to find problematic packages that we can add to this repository. So, it's both a problem that we haven't... We don't have this community of testing users which is actively telling us what's not going on, what's not working currently. Also, when you try to look, for example, in the list of current RC bugs to find packages that are not working well in testing, you will see that most problems, most RC bugs are not really user issues, but rather developer issues, like packages not compiling or that kind of stuff. Well, I mean, when he announced it, I tried to have a look. I found maybe two or three packages that were problematic in testing, and the result has been a few aging hints from the media, I guess, to make them migrate sooner instead of putting them in this repository. Another thing that it's been working on during DebComp, it's Joachim Breitner, has suggested to use a new technology, SADSolvers, to improve testing migrations, and we can use it, we could use it, at least, automatically to make Jocelyn's experiment more reliable, because, well, basically, you can give it a list of packages that you want to migrate and it will compute automatically the minimum set of stuff that you have to pick together to make sure that migration won't create problems in testing or rolling, however you call it. So, well, my first question would be how to set up the user community side, because, I mean, if we want to have some clear feedback on the question, is testing usable, we have to go see users and ask them what's not working in testing and grab some data, so I would like us to provide a place where people, well, a few developers and the users can meet and exchange and see whether what we can do to improve testing right now, and maybe after a few months, we will be able to see if really a separate repository like rollingdebian.net is needed or if it's enough to collaborate with release manager to get fixes in. My opinion is that it should be enough, but maybe some hard data would be good. And then this input can also be useful to the release manager because, well, if we know what's blocking users, maybe they are keen to fix stuff in a way that, well, organize their migration in a way that ensures that bugs are fixed sooner for users or at least important bugs are fixed sooner. So this is my first question to you. Where should this happen? Do we have an existing mailing list that can be used for this? Should it be part of Debian users? Should it be part of Debian testing? We have this Debian testing list, which is mainly used to process upgrade reports, but it's not used during the rest of the lifecycle. Maybe we can use it for this. Should we have a dedicated pseudo package in the BTS, rolling.debian.org or whatever? Or should we reuse the release.debian.org entry? I don't know. What are your opinions here? Maybe do you think it would be reasonable to use the release.debian.org entry with a few sets of user tags? I think if we are going to propose some hints, for example, or spot some packages that should migrate faster than others, it would make sense to use the release.debian.org to the package, the BTS, so that we can set up hints for that. So it's okay for us. This is when we have a clear output already. Where should users say, okay, I experienced this in testing. My camera application doesn't work. I don't know exactly what's broken. Should this all be hidden in the various bug tracking discussion or bug reports? Or should it take place on some mailing lists? So one recent initiative that I noticed was there's this IRC channel, deviannext, which seems to contain the target audience for a rolling release, or at least some of those people who are not developers but are nonetheless interested in using SID and testing. So that could be a point of contact anyway. Obviously an IRC channel is not necessarily your canonical support or interaction place, but there's some people. We have set up a copy entry, so feel free to complete with what is suggested here. Luca, can you note the deviannext IRC channel? I can try. No, it's in 5L. I've already studied a bit bigger, but enough? Actually I had a question for those who think that testing is not usable yet, because our person is thinking that it is usable, and if it's not, we have a big problem because we make stable releases out of that. So it should be usable, and we don't break packages so many times. I agree. Let's give the voice to Luna and Olga. My main issue is about security, actually, because I'd say we can't advertise to our users a distribution that has no proper security updates, because as far as I know, the security team is not interested in doing dedicated updates to testing, so the security issues are fixed by specific patches in stable, and by newer uploads in unstable. Issues that newer uploads in unstable, they can get into transition issues and not migrate to testing soon enough to protect our users. I think that's my reason why I don't think that testing should be advertised, or it's totally usable by users, because if we have some massive security issues, then it's going to be hard to avoid bad PR and stuff, and people saying that it's like we had for the open accessible issues. Actually we've already had this discussion several times. It's not really a true issue, because either the maintainer cares and he can do a TPU upload to get it sooner, or he don't, and it will be fixed anyway when the packet migrates, and usually there's an AC box associated, so it's tracked, and the RIS team tries to get them in quite quickly. I don't know what someone made us study, and usually you have less security bugs in seed and testing than you have in stable, because quite a few minor security issues tend to be not fixed in stable, while they are fixed by new upstream version in seed. There's also the testing security team, which is currently inactive, but all the infrastructure is still there if it's necessary to start spinning that back up and actually doing the work again. And the past testing has been maintained near to a level of stable as far as security fixes. Yeah, and the security tracker has the information whether while a packaging testing is very variable or not, so I don't think this is a real concern for all of us. I just wanted to mention TPU, and usually when you fix a security bug, you upload with a high priority, so it gets migrates quite fast in two days, and you can make it faster if needed. So any other suggestions maybe for where we should meet our users, our testing users, because we had the test-debian-next IOC challenge? May I ask a question? Who is the intended target user? Is it an existing Debian user who wants to not be locked into an old distribution and wants to take a chance on testing, or is this for a new user who might be choosing between Ubuntu and say Debian Preview or something like this? Because I'm not going to recommend a friend of mine to start using Linux distribution by saying Debian testing, I would be more likely to say, well, Ubuntu's got newer stuff than a one and a half year old Debian stable. Well, users, as though they are keen on using it, I mean, I'm not going to force anyone to use it or to not use it, but yes, clearly one of my motivations is to enlarge the potential user base of Debian, so I'm keen on attracting new people to Debian with Debian testing. That said, we already have users, and we can also try to do better with those that we already have. I do think that there are interesting target users for testing which do not use testing now, but they use Ubuntu, and these are experienced desktop users. I do not think that we are set up to handle Linux or computer newbies or computer just Linux users in the main sense of the world, but very well now, maybe later, that can be done. But a person who is a bit knowledgeable and interested in infrastructure, in the Debian infrastructure, may be able to use testing already now. I think that's a bit also a perception problem because I don't think that Debian Stable is unusable for users and can be installed very easily, so I think that if we are constantly saying Stable is not usable or not suited for users, I think that's wrong and a problem. No, no, I mean stable. You are constantly saying Stable is not suited for users. Stable is obviously usable for users, but it's not attractive to desktop users who want the latest and greatest. Testing is perceived as not usable for users. As far as the users that we are targeting, if we have a rolling release like testing, you're correct, we would attract the more knowledgeable top end of the people who want new stuff. I think if we want to attract more people than that, we have to find some way to do something more snapshot-like so they don't have to deal with constant potential breakage. I'm not sure if it's me or... So yeah, I don't think anyone is saying that Stable is not usable. I think there are just different targets. So I have in mind when we discuss about rolling at least two targets, which might benefit for something like cat or rolling, and one is the one that Joy just mentioned, and another interesting target of people who might be interested into that are developers in the sense of software developers which want a stable system without risking Udev which breaks down and fuck up one day of work or any other package that breaks down and fuck up one day of work, but still need relatively recent development libraries and the like. So maybe when I come back to my question of where do we meet those users, maybe we don't need a new place but you need some documentation, advertising this documentation on how to best be testing users. Do you think this would be a workable approach? Yes, sorry, go on. I wonder what is not covered by the proposition of Jocelyn because it allows some flexibility around testing and it provides something that is more or less working. And then we of course have the problem of the freeze which should be short and during the freeze the users of this testing thing don't get the updates. But then what should developers do during the freeze? We want them to fix RC bugs and some people do, some don't and one of the problems of the freeze is also that you get late on following new upstream releases and people don't like to use experimental for this because you get various dependencies problems so that's something that we should fix or somehow find a way around. But yeah, my initial question is what is not served by the proposition of Jocelyn? Well, given that Jocelyn's proposition is just to have something on top of testing it would work for me, but I fear that we're never going to have much interesting stuff in this overlay repository. So well, you just introduced the next question so how to get rolling rolling? How to start with it? Well, the proposition was to just make it a similar to testing because as we see, most people do think that testing is usable as is. We can do better but there's no reason to have new infrastructure except maybe some documentation or some place to discuss issues with users. But given the feedback I have I just got it. It seems like we don't really need a new place to discuss. Maybe just use the BTS and some documentation or web page listing current issues so that people can be aware of what's not really working well in testing right now. So while the similar approach is just a marketing operation is true because it's a way to say please come, we believe testing to be usable and if it really turns out that we need some different rules compared to testing we have always the option to replace the same link by a true distribution. The other option is to make it a dedicated distribution right from the start. Of course that gives us more freedom to try new rules but it gives us some more risks to hamper the stable release process because well if we have conflicting rules then we might slow down the stable release process. And if we go out for a new dedicated distribution we have to decide for a set of initial rules and it turns out it's not so easy given the numerous discussions we already have. So do you believe that while just doing a rolling same link is reasonable or totally useless or okay so who believes that this is a good idea first? Okay a dozen people and who believes it's totally useless? Okay six or seven people so most people do not care apparently and well at least Neil said he doesn't care really. Who believes that it would be important to start with a dedicated distribution so that we can try out new rules from the start? Well, intact languages. Is there anyone who believes that we should have a dedicated distribution with new rules? Okay, Clint maybe can you expand what would be the new rules if we do it because well, Clint over there. Well, if you're restricting to the subset of architectures then you don't need to wait for the other architectures to build fixed packages and you can migrate quicker. Yeah, but then we have the problem of the difference between testing and are there going to be people who don't care about getting it fixed on the PowerPC because the PowerPC is not considered so it's a kind of trade-off that at least at the moment is difficult to evaluate. I understand the idea, we could do much better if we really concentrate only on two architectures but we're not there only for rolling, there's also tables so yeah, Phil or Peter first? I have another idea maybe sometimes we expect and we know that some breakages happens in testing because some migrations and things like that and maybe when we know that this will happen we can make some kind of lock or I don't know which locks the state of the archive or the distribution in a usable state and maybe just stays the same for the few days and then it becomes unusable because it happened maybe years ago that x.org become unusable and it's such a critical thing that if we want to propagate these to end users we must ensure that I don't think it's going to work out because you don't know it before usually once it's broken you know it but before that would be a way to but we're not supporting downgrades we're thinking to our mirror every six hours so it's not an easy problem yeah Phil? Right, if we have several rules and that allows people to focus on things like only having a few architectures I see a serious danger that will end up with effectively a derived distribution which doesn't really ever meet back up with Debian because I think the release process is a bit like the point at which the gametes are passed on to the next generation and that if you don't force everything through that one moment that you get divergence and new species you know the whole point of reproduction in nature is that there's only one set of gametes going into the next generation if you have a species like bees the queen bee is in charge and it doesn't matter what the rest of them do there's that moment and then you get the next generation that happens at release time in Debian if you have some side branch then some people will focus on that and you'll just have something else it won't be Debian anymore and also the problem with different distribution is that you have much more combination of potential problems we want to fix problems for the next table but also for rolling in this case you really divide the user base for the testing in this case it's also one of the reasons why it's not such a good idea to have a dedicated distribution yes Peter? yeah just short comment on the last one before I move on I think it's our we'll divert resources if we are actually sitting packages and have to track versions in basically a network instead of a sequence of versions and merging and upgrading and such systems will be interesting to say but my main point is I don't really get a point on who is actually the target group of this proposed suite is it the Ubuntu users? if it is the current Ubuntu users we are focusing on the wrong area because when I install Debian for my parents for example the biggest problem with Debian is not hardware support it's more like the lack of proper handling of multimedia plugins and the browser plugins the fact that Firefox doesn't handle the text mime type properly it's asked me to start Emacs instead of actually showing it in the browser it's that kind of simple usability problems that is blocking my parents use of Debian it's not lack of new versions so if we are going to attract the Ubuntu users we have to fix those problems first and I'm not sure who is actually who are we trying to get to use testing, is it ourselves? who is the target group of this effort? I think we already replied to the question before Zach mentioned for example developers it's a particularly interesting target because it's a set of people where we can find contributors but I don't have any restriction of target users I just know there are a lot of users willing to use Debian and are looking for something a compromise between stable and stable because they are not able to fix up you'd have no longer working but they are fluent with Debian tools otherwise I'm going back to the questions that you asked during the poll and I'm really interested in knowing more about why some people are opposed to endorsing the rolling idea rolling or testing, rolling release concept endorsing it what are the fears to why do people believe that we should not advertise it more, is it because of resource there's nothing after I don't really see the point of having a sibling meaning that we would have two names one would be testing, one would be rolling if the name testing is wrong then let's discuss that and rename testing as rolling that's it, end of the story and we end the discussion here so if we make something called rolling I think obviously that's to make new rules we must start at some point it's true that we could just rename it but we have to keep the testing because many users have it just for compatibility but also as we heard there's always these questions that we intentionally avoided today because I know it would not fit in the slot but keeping both names at least allows us to make rolling diverged during freezes I believe it's I would like to see it happen but given the time the state of the discussion with the release team I'm not sure it's realistic right now but one day it would be nice to have it so keeping it as a second sibling leaves us the possibility to do it at some point so my time is over I guess we'll have to continue somewhere else or after the recording do you really need to we really need to stop because there are people needing to eat and finish the room and prepare it for the afternoon so thank you Raphael