 So ladies and gentlemen welcome back to our last talk here in inter-school lab The next big here needs no introduction. So there is none. I'm hello. Thank you for all coming I'm sorry. The room isn't bigger, but I wanted this to be a boff Can you hear me in the back? I'm sorry Good, okay So this I'm Lucas Nussbaum was gonna give me a hand. I'm not sure if he's here. There you are. Okay, so I think we'll probably both end up co-moderating whatever discussion we have So I wonder how many of you have seen this web page Could I get a show hands? So it's almost everybody in the room Well, that's a good thing. I wrote this thing back in I think it was 2007. It was back when I had hair And I sort of at the time intended to be a kind of a meme so I think it might have worked because at least I got everybody in here maybe and the basic idea behind this is To make testing a little bit more like maybe it was intended to be Or maybe not it's I won't so I won't speak for AJ. Okay Right Yeah So so I won't I won't okay. We testing wasn't AJ's idea then so anyway, I won't go over the details Right, I won't go over the details of the things It's almost everybody's read it but the basic idea behind constantly usable testing is just to Find a way to make to allow some percentage of our users Let's say 50% or 25% of the ones who currently aren't very well served by outdated stable releases that happen every couple of years which is a great thing for a lot of our users But for the other ones to give them some kind of release based off a testing that works reasonably well maybe say as well as a boon to or as well as some other non-enterprise level release and So that's the basic idea the question is can we make it work and can we make it work without a lot of work? Yeah testing not currently Okay, always usable right so there's a couple of reasons you can start off at the installation level new releases of the devian installer that install testing Happen and then sort of bit wrought away until they no longer completely work You'll have installation DVDs that will continue working pretty well But all the other media doesn't work and also maybe di doesn't get a release for testing until testing has been You know until testing has been in development for a couple of years like happened just currently we currently have had one di alpha Since the last release of devian so before that alpha there was no way to install testing and now it's six months old there are other issues of course there's Sometimes the release team Decides to remove packages from testing just because they have RC bugs and they feel that they want to get the RC bug Countdown and maybe motivate people and of course if that's a package that a user needs and Testing won't be usable for them, but that might be just for that user They're not gonna pull X out or something hopefully so I think there's all kinds of issues and I'm glad that people are adding stuff I'm sorry. The headset doesn't fit me Yeah, I could the headsets there if someone was to run around with it Yeah, yeah, I can repeat questions. That'd be fine So what I wanted to do is just get all the teams in one room Who would be impacted by testing and as well as anybody else who's interested and just try to I mean Like who would be impacted by a constantly usable testing and try to hash out how it would impact them To what degree and see if there's enough interest to actually do it and there's a question in the back And I'll repeat it Or not Okay, so one of the other reasons why testing isn't always usable Which is also one of the things that we're gonna need to address with this is that right now There isn't a separate stream for testing between security Patches and regular updates. That's not true. Well, there is a separate testing security team Right, what I'm saying is is that there's so if you need all the security patches for what you're running You can't necessarily only point to testing security because the security patches may be for a later version of the package Then what you're currently running kind of a thing? Packages that are up to the testing security update should be installable against testing. I mean, I could be wrong my understanding was is that Not every security fix goes through testing security. Most security fixes don't go through testing security We have more it's here which and is there any bails in the security team here? Okay My understanding and please correct me if I'm wrong on anything that I say is That there have been about five updates that went in through testing proposed updates since the last stable release Every single other security hole has been fixed via normal propagation from unstable And there's some delays associated with that But if you look at the number of say current issues right now, I think that testing has Maybe half as half the number that stable has and unstable has half again as many is that about right? So what that implies is that you is that I haven't made my point clear my point is not the testing doesn't get security support I know that it does my point is that in order to get security fixes for your testing box you have to upgrade and That okay, and there's a lot of package churn in testing which means you're doing a lot of great And the so if we have if we made a test if constantly usable testing work by having a release And then waiting six months and having another release if you want to get a security update You might have to upgrade all of acts and it might be broken and there might be some other issue of course Hopefully testing would at least keep the dependencies consistent and you could upgrade and it would all work but Also, you're dealing with upgrades and of course upgrades within Stay within unstable don't always work and upgrades within testing may not always work either So, you know to some degree this is the thing that testing can't satisfy as well as stable does because we can't Check that upgrades work quite as well And there are more upgrade scenarios than there are with stable They mean bashing the six months, but making sure that security updates are available independently before six months What does the right one address the problem? I'm not saying that that's not a good solution I'm just saying you know your one thing that makes it unusable right now Is there's so much churn that it's quite difficult to keep up to date and feel secure? I think you're right. So maybe the solution is another queue and another another archive that then has Any security update that gets into testing is basically back ported to the previous Constantly usable testing installation release or something that I'm into the implementation, which I'm not sure about of how Constantly usable tests would really work. I think right right so in fact I think one of the biggest problems joy is is calling it constantly usable testing Well, that's focusing on the notion that what we want to do is make testing the thing that we're talking about When we had the original set of conversations in my office in HP a whole bunch of years ago between three of us who were DDs at the time about what the problem was at that moment And at that moment it was that the way we did a stable release was we made a copy of unstable called it stable And then work to try and make it actually releasable if you weren't around back then Man, you know the world is different than it used to be And what I observed and what I wrote an email about was that I thought the vast majority of our users actually wanted something in Between those two states and that's sort of you know, what you've been echoing on all of this and then when AJ Read that and went oh, yeah You know as the person trying to help work on or a person trying to help think about how we should do stable releases This is a great idea. Let's have a rolling release candidate and let's be doing that what we've ended up building and testing is this process That's all about Promoting packages in in a way that leads us towards something that we would want to release a stable And I don't think it's the same set of promotion rules You'd want to have for something that you know meets that original set of criteria. I think you might be right I'm not it's I think it's really hard to say exactly for sure But I do know one thing which is that if you have a different set of rules You have a team that ends up doing an equivalent amount of work that the release team does now and that's a lot of work Well, except that I think you know With respect Rose this is something we could probably have a long philosophical discussion about but what I always thought most users Really wanted was unstable without the brown paper bag bugs that the notion that every time you looked it was sort of fresh And new and good was in fact what certainly on the desktop what most people really wanted it this The well because that's the propagation delays Yeah, because that's inconsistent with trying to create a stable release because stable releases are all about managing You know large package interdependencies, right? But you know, I also I mean if you run testing I think that the propagation delays and all that kind of thing. They don't make it unusable Correct that so I think as far as constantly usable testing goes it is usable in that regard Right, it might be a little bit out of date. It's not horrendously out of date X is probably new enough the Keith will actually be Yes, although all the client machine how you to install something of experimental and will probably work Yeah, all the client machines in my house other than mine run testing. Yeah, and so I mean it's not impossible It just it does read so I mean interesting issues from time to time So I really feel there's and people please tell me if somebody writes something interesting up here Because I obviously don't have time to read it all but I think that there's two brand There's two basic approaches the first approach is just doing cut releases which are cut so testing you just stop there You say we have an installer that works. We have a desktop that works basically we hit everything old seems okay There's nothing horrendously missing. We take a snapshot We don't change the snapshot again, and we have a security update queue type of thing and we have installation media and I think that is not a horrendous amount of work. It's kind of It no, it's a different kind of stable or It's not the same because if people who are running this I mean one way you can do it is you don't have security updates So people who are running it want security support want ongoing support They didn't they installed and they upgrading follow testing along or they stay where they are so It it's more Just formalizing what we already do which is having DI and releases and all that kind of thing so I mean I wanted to throw out is that I think we have sort of problems at both ends of the spectrum here because We've now built a set of project Infrastructure processes and teams that are all about getting to the next stable release for whatever definition of a stable releases that we're operating under at that moment and that that sort of It causes problems at both ends and what I mean by that is I wasn't joking earlier today when I said I want unstable to become unstable again We've had a number of conversations this No, this doesn't but but while people are thinking about perturbing the way we currently have packages flow from an upload to a stable release and in various paths and detours they may Take in the process. Let's also think in terms of how do we get to the point where the thing that as Developers and maintainers of Debian that we're running on our development machines and our development charoots or however We like to live is really up to date all the time and current and interesting and worthwhile And that means not you know finding ourselves in a situational with great frequency where we're gating Uploads to unstable on the basis of that's going to trip up some transition and testing Yeah, that's obviously Maybe No He's asking if we need he's asking if we need a freeze before basic before a cut release basically and The answer to that is no because what you do is you just look at the current state and you find a good one Or you find a reasonably good one. It doesn't have to be perfect. It can have some things broken You just document them and you say don't use these things if you're using this cut release That means the the subset of packages which you want to make sure work well individually and together Should be quite small. I would say that subset would be the ones installed by DI on a default install plus a few other things Like useful servers. So the rest are used at your own peril. Exactly. Yeah I think if you look at it as a as an Ubuntu universe Multiverse whatever they call it model It's that might be a reasonable way to go about you know cutting through the best best complexity of it all Hi dropping things left and right. I'm also a sheesh. Hi Hi, hi Yeah, so We're talking about cut releases that are just snapshots of testing and I want to contrast that I think that that's not something I'm interested in using I'm interested in maybe installing that and then setting sources listed testing is Well, how do you isn't that what everyone wants? Do you think that everybody wants to follow testing all the time? I think well, I mean, I think that the Isn't that one good thing about having the releases is that you kind of get two things You know you kill two birds with one stone You can have you can satisfy both groups the users Assuming that you can actually satisfy people who want to follow testing Right so they can have a Semi-stable release which is just to install the snapshot of security updates or they can install and upgrade the testing and follow testing It means even still it isn't different. Well, okay, you're right Okay, no, no, no keep keep No, no, no the difference is that you're keeping testing usable So you're trying to deal with issues that are keeping They're keeping testing for being usable on the going basis while all this is going on So you make a cut release and then you say, okay, we're gonna make sure that upgrades to testing from this or working Okay, and we're gonna make sure that testing we're gonna try to make testing work better for people That's basically the whole idea behind this so You could you could upgrade from stable to testing it doesn't matter how you get to testing But once you get there it should be something that we can say to users This is something you can use not this is something you can use to test Debian and I mean, it's partly just a perception thing We probably just have to make a commitment if we decide to do this that we're gonna tell users That's the case and actually fall through with it. Does that answer you? No, okay. Well Okay, so I just a comment on Comment on what we did said so it is true that we have now created teams which kind of Oriented new releasing how we do that now how we do releases now But what I find it really interesting in the way joy presented cut on that web page is that it seems to be quite Orthogonal so it seemed to be something that can be implemented by a new separate team without impacting too much with existing Infrastructure so I think a very good exercise to do here would be to actually kind of you know Being the devil attorney of your presentation and checking whether it is really something which is orthogonal to the rest Whether it is really something that does nothing back too much on the work of teams like security and right So I appreciate that we go Philosophically on whether it is something we do want or not Yeah, but so I mean if there is some people interested in doing that the most useful thing to do here is Verifying how much it impacts on the world so that's these things down here, right? And we should have a release team thing somewhere too. I guess it's under archive. So I guess we don't have any FTP masters in the room, right? Oh Hi, okay, sorry I don't I'm not up on who's FTP master team or anything. Who do we have a release people in the room? Okay, hi, that's right. You're new okay, um So I've already, you know Ganna already posted a little bit about how it would impact the archive The basic gist of it is if you make I think is if you make a snapshot and you don't update it there's an initial little mirror head of 300 megabytes or so for the packages files and that's fine and The extra space I don't think is of a huge concern if you have a rolling release like another version of testing with different Policies or something. They're not quite sure how to deal with it They might have to remove some some packages files and aren't used a lot because it hits a mirror every four times every day, of course So I guess the other part of the top when there is release team stuff I Don't know I I'm sure that Constantly usable testing could make the release teams job harder, but I would kind of like to hear their opinion on it So Well, I'll certainly let Adam follow up on this as well But I think we just need to work out what we want to use testing for I mean certainly at the moment the the the use of For example, it says Yes, important packages get temporarily removed and it's not just for RC books Again this is for transitions actually transitions and various things So the ability to intentionally break testing is very very useful to be able to get stuff in and It's a case of of how we do that and how we manage I think it's a case of managing it if you can you know If we can know that testing is in an usable state and somehow communicate that to users for a while Or let them install an upgrade later or that kind of thing. Maybe that would work Could it be just called constant frozen I Don't see how it's frozen though We don't want it. Oh, it's pretty much the same kind of say you decide the snapshot And then you just allow packages which you think they're useful Yeah, but I don't think that we're trying to push in individual packages to a snapshot because then you have dependency issues And it's a big mess and it's a lot of manual work, right? so So I think one of the things that would be really useful is if somebody could come up with a good metric of Determining what the state of testing is currently so you could have a weather report that says yes today testing is stormy Do not install. Yeah, I Mean I you know I used to run automatic installation testing for several architectures only I 30 680 64 really matter for this I guess and you know, you can get a failure report You can say testing doesn't install or testing you can you could see if a desktop came up maybe that kind of thing Oh, I think too. We could also have even just straight dependency graph Oh, yeah availability and packages are missing so that could be calculated right in addition to obviously we need real life installability testing So so the original thought we had and all this was that you many years ago like 97 was that this thing between Unstable and stable would be characterized by the fact that it would be churning faster than stable But it would never be structurally broken This leads me to ponder sometimes what it is about testing and what it is about the promotion rules in the testing or the Overrides that we have to stick in to get around the promotion rules the testing that causes it to actually be broken I don't think we I don't know that I would call it broken at any time I mean it's always and it's always in a consistent state It just might it might not be in a state to let you do exactly what you want to do as far as you know If you want to install a new piece of software, but the old packages that you have install will continue to work fine Yeah So Zach said there are more packages than you use and if you try to install one then it's not useful For you so packages can are periodically removed from testing for various reasons part of the reason is as needs said because they are Assebagi and we want to release another reason if we have a big transition going on And you have to remove a couple of packages from testing if you want that transition to happen and for for a thing like cut It's not acceptable that one day or two day or for a week a package is not installable because it's just not there But Zach to follow up on that it is except I think it's acceptable if Well, one way you can do this is you can have two lines in your sources list and try to install from the old cut snapshot But I don't know if that would really work because of dependency issues. So it's kind of hard to think about I really wonder about the differences between the new approach and the old approach because the The hammering transitions in thing isn't much used It's used as a last resort breaking Architectures that are not the main ones. So they shouldn't break anyway And if you say it's mainly MD 64 and I 386 anyway where you did your testing only those method those should not be broken at this point and Do you have any example of an important package being removed? The only examples I have or that I remember running tests again trying to install something that it wasn't there But I can't tell you what it was and it wasn't something highly important It was probably some random small leaf package that only I use or type thing. Yeah, okay. Yeah, it's about leaf packages. It's through Something GPS isn't intestine Just just as an example right now for example Tango GPS is not installable in testing Because it was renamed to Foxtrot GPS and the new Foxtrot GPS package Provides a transitional Tango GPS package But the Tango GPS package was removed from testing because the source package is no longer in unstable So somebody asked about the the reason why you wouldn't just install testing and install stable and upgrade to testing and the obvious reason that we see all the time is that stable just doesn't support your hardware so the There's there's something a bit further down there about Di installing a snapshot and I think that would And you know the work we do and beta release and things. I think it would really help di I think it would run into a number of situations where we spend a lot of time spinning our wheels dealing with some issue That won't affect stable in the end or not even that sometimes we sometimes we have problems with you know We can't install because that's what I'm talking some Some package in testing change of semantics and the installer hasn't been changed Or the alpha release. Yeah, right. That's why I'm saying that the installer generally bit rots down to not work Right, so if you think the who lot together exactly who lot right and that's why I think that having an actual release is a good idea I don't know if having a separate rolling release on top of that is also a good idea or not and my feeling is that we could start by doing the one and See how well users take to it and then maybe think about doing the other one if it comes to that but I think doing the other one would be a lot of work and I Would sort of like to hear from the release team if I'm right on that. I mean So we have a couple of downstream distributions that do something like this obviously a boon to you and we're not gonna Have a boon to emerge into the devian release. There's also sit-axe. Oh, yeah Mepis. I think also does something like six months releases on top of debian. So Can we reach out to those people and just ask them to maintain Mepis inside? I would love to recapture those people or capture those people. Yeah, and I think I mean and I would When testing is cloudy, I think we should just I think that there should be well like stable testing Testing when it last wasn't cloudy unstable Yeah, and I think Testing when it last wasn't cloudy one easy way to get there's just have a cup release a snapshot It would be nice if it were a snapshot that were constantly updated But you have to do a certain amount of manual work there So I kind of what just wanted to reply to Phil so I'm very much sure that most of the time Testing is not broken that most of the time all packages out there But I think with something like cat. We're trying to we're trying to reach out a kind of new eye of you Which wants something like stable, but which wants just more up-to-date software And we most we mostly have that already with testing, but just just not quite It's a perception as much as anything else. Yeah, and testing as we have it now It's kind of unique in distribution out there So I think the point of cat is just thing is just adding that that mostly I mean what we miss for for being really a Stable a mix of a stable release with updated software So even if we but it is okay most of the time We need to fix that most and making it all packages are installable always. Thank you so much for pointing that out that Having a rolling release that's always usable is a something that as far as I know no other distribution does and be Sorry Well, okay. I'm sorry Yes, but and be something that basically fits the world as it is today and not the world as it was when distributions were shipped on floppies, so I guess let's see we've covered have we covered security. I was gonna say. Oh, I'm sorry. Go ahead I just heard the one main problem that people have brought up was that maybe a package isn't Uninstallable sometimes in in testing and I don't know how How often you actually run into that if you're a user and you have to get install ice weasel and it's not there I don't know how many times that happens. You may already have it installed So I think that the situation is where that happens happens is very low But we can we can fix that by just communicating to the user like after install ice weasel and it can't be installed in testing Right now, so it could just say sorry right now. It's in transition. Try again later. Yeah, or So actually let's let's get down here to the bottom of this thing and talk a little bit about Marketing type stuff. Do we have do we have people from the publicity team in the room because I neglected to invite them? But I think they got invited in the end right anybody publicity team or marketing or Website anything like that But they don't want to raise their hands Well, um What will we call it I Don't know if we can get away from the name testing right now I don't know if that's the most important thing to do. It's kind of a code name You don't even actually see it if you install testing That would be great, but but but what my actual what my original Thank you for all the thank you for all the bike shedding My original proposal was just to call it cuts of Debian or cuts of lemmy or whatever And so then you you have the first cut the second cut and then the final cut which is stable So thank you for that in So my question my question, I mean what I want to get out of this I think I've kind of got Partially and we can have as a big long thread with all kinds of details at some point It's just a general feel of whether the affected teams or release team the security team etc Feel like this is gonna be a horrendous idea That's going to cause them a lot of work and make it impossible to ever release stable and stuff like that or We have a hand in the back Sorry, oh, I'm sorry. We have a hand in the back from the video team So I wanted to get that idea and I sort of get the impression that people don't think it's a bad idea right now Hey, Joey, sorry just really quick you had said You had said earlier. I thought that you had two procedure two ideas about how this would work Did you did you outline both? I'm sorry The first procedure the first idea was to have the cuts which are snapshots Which are basically sweets in the archive name something like You know when he cut one or something of that ilk and the second With whatever frequency is managed best It could be every six months. It could be every four months I don't know I think we've if you look at Debbie and the Stoller releases and take that as a baseline model The best we've managed is every four to six months. So that's my feeling And then the second option is to have some kind of a separate suite that's updated four times a day just like testing that has different rules of what goes into it and My feeling is that's more work and Colin has a I guess I was wondering how we'd go about This kind of matter how we'd go about testing the cut in advance of its snapshotting Well, I guess you want more than four hours to test it is the question. I think what you do is you look at the I don't know Colin. Maybe you maybe we have to have a way of doing a snapshot and then renaming it You know something like that Right now we have a rule that's only we support upgrades We support upgrades only from one release to another, right? What are going to do that? This is something that the cut team has to deal with clearly They have to figure out if an upgrade is breaking between the previous cut and current testing And if it is breaking they have to file bugs about it. So they have to do some kind of upgrade testing and this could be something that I mean Partly things will occasionally break and we can't as I think I said at the beginning We can't guarantee the same level of stability clearly to users who are using a rolling release But we can check upgrades between one cut to the next cut So people who just upgrade and then upgrade again in six months or whatever we can make sure that works For almost all packages just maybe not quite as well as we currently managed to stable because we take a couple of months To really look at it in detail, but we can still get a pretty good idea and there's a question in the back So I'm sorry, but I don't really see the point of Snapshots every six months because if you if you want to snapshot testing every six months and release that I don't see And what's the value we are going to add to compare to open to? Okay, people know I'm just not finished I think that the real good point about testing is a constant constant flux of I agree packages And that's what users that we target want, but the only way to get there is to install Testing or you can install stable and upgrade, but that assumes that your hardware works in stable So it's a way to get to testing. It's also a way if you don't need completely the absolute newest stuff It's a way to Stay at a nice baseline and then jump up another six months in that case We only need installation media every six months snapshot of installation media every six months. That's right Mm-hmm. We already have installation media snapshots to testing or ongoing and best effort basis and they generally work It really does I'm sorry, I didn't realize you're in the audience. Hello Okay, so a few things yeah, you can hear me. All right So when we started doing when we started doing testing As far as security installation was concerned installation was by bootfloppies I don't know how many people here remember bootfloppies, but If you don't you're better off not remembering And it would take years to get bootfloppies updated for the next table let alone doing three or six or whatever monthly snapshots and Security we didn't really have we have no idea what security holes are in testing or stable or I mean we're unstable at that point really Some people have mentioned about the weather report for for testing at the moment there is one broken pre-dependency in testing and About Two Can you tell how many packages are in say unstable that aren't in testing that used to be in testing? Not on the web page that I've loaded up. No So one of the problems with testing is that it doesn't ever check that two packages are installable at the same time So you might get to the point where Numerics installable, but not Katie at the same time So there are things like that that just aren't tested that kind of thing you want to test by basically doing Installation testing and installing a task and making sure you have a desktop within all the packages you need or something like that or so You could even do it by dependency analysis and The other thing I would have thought would make sense would be doing a snapshot of all the packages and then doing the Doing the build of Debbie and install. Oh, no, you're right And well actually that up and that gives you maybe a week two weeks to for sure We would want to do the CD build against it I Do the installer build against it the installer isn't really that dependent on exactly what version of Debbie is built against Unless you're really worried about say libc having changed or something So so I guess the thing I meant more for that was just making sure that in the last four hours Nothing had broken the installing testing as you made the snapshot Okay, I just wanted to say You want to know how it impacted on doing support The project I'm working with Debbie and EPC is there because We have to have Debbie an in a state that works for people who are getting the latest models of EPC And that's always changing and so cut would exactly address that What I'm having to do now is say use the daily installer and that's not always working for them So that causes extra support cost for us that we can't necessarily handle So cut is ideal from that and the other thing is I'm using Debbie in life to build Now we can do and then combined installer live Image and so this gives them at very little risk To be able to take the next cut release and try it out and see if it solves the problems that they've been having And then make the decision to go forward or not So very good Hi, I'm Hello Hi, I'm Drake Dietrich. I am And one of the people who wrote Deb Marshall we did something where we took one extra layer of Subdirectories inside the discs and you know the name of this distribution And then we kept every single one of the packages files that way when we created sim links between the different subdirectories We could go forward go back and never lose anything and Do further testing on each one of those snapshots and be able to adjust our sim links to keep track of everything Right. I don't think we have to deal with sim links. We've I mean that's good at doing sweet some stuff And we can have multiple snapshots as far as I understand without too much overhead Well, it was the main thing was to be able to do things like Different people have nine days out of ten even unstable is perfectly good and usable So if you keep the snap keep a sim link to the days when it's good, then it's much easier to Risk the the 10th day Hi, my name is bad young And I've been running testing for Longest amount of time because I was simply tired of having with stable having to go and hunt down Back for it and so on so forth One thing that I do is if I install it I install at this bug also Yeah, and that way I Can track what happens is great as long as you have a fairly technical user administering the machine Yeah, it's sometimes even though it says well this package don't install. There's something wrong. I said, okay It's changed some other stuff. So they've been doing pin the package, but it also sometimes breaks the package So it's not perfect, but it keeps me a breath of exactly what might be wrong with then Testing at a particular moment in time and so they are for but for the most part my laptops my servers are running testing and I like the fact that I'm always question I think I think that most people in the world do they kind of expect that as the default you know They get it on their phone. They get it. Well sort of on their phone You know the the expectation isn't that they're a big model of releases anymore And that was kind of the whole inspiration for having cut There was Kind of worried about the periods of which you are trying to do the cuts Because I think it might dissuade users more from using your cut at system I suppose to cover that small percentage the use games. I'm thinking now is that This process has to be as automated as possible with at least the least possible amount of human intervention So you will not be able to do enough quality checking and that it's in the best possible state It's something Not exactly definable so every cut release you will have at least some amount of packages broken Oh, I think you're probably right which means for system For people using that cut release. It's completely unusable because they cannot wait out in the next no because Generally the things will be broken won't affect most users you can test for the things that affect most users You can't test for a long tail of things that don't but what you do with a long tail is you tell those people if you're using This list of packages you need to upgrade the testing after installing cut So but I what this means that at every cut release you will lose like 1% of users Right they might not want to be great because they're already Happily using then which just so so you're a you might be right I I think that what what it sounds like is gonna happen if you're correct Is that we're gonna reach some kind of a homostasis where the people who are using cut or the people who are desktop users say And I think that's probably okay I and maybe they're not desktop users who are doing say the previous talk in here was about multimedia You know music stuff Maybe they're not that set because that's too broad a set for cut to be able to handle and maybe that's okay so my suggestion basically is To do a cut as often as the automated testing System allows you to verify that the testing archive is in a reasonably sane state To be able to look at the state when we do the cut and take pick the right moment to do it And but you know if we look at it We already do this to some extent we wait to make them install releases until everything is until the moon's aligned basically, you know So my comment is kind of related to this one basic question We should ask ourselves is whether when you take a cut you are allowed to you're allowed to change something before releasing the cat or not If we are allowed to change it Maybe that can easily fix that one percent of packages which are broken But the second point I was make I wouldn't like to make is that If we just say install from cut and then upgrade to testing We will back at the problem that on some days User can miss some packages and I think this is not a septel or set above if we're going if we're going to propose these two Users like you said desktop users So I think we should have two baselines when you still cut you get the baseline of the cut and you get the baseline of testing Maybe the baselines of testing is Optionally enabled or not and the point is that if you're missing some so you're saying you're saying to have both cut and testing and So if you know what I'm saying is that if we want to give testing to cut users Then should not be a remove cut and go to testing. No, it should be it should be cut So you so doesn't use by the exact slash testing and you get that if someday a package is removed from testing You have a fallback from cut from the last cut. I agree with the provisional I don't think it would work all the time Also, you you sparked an idea in my head, which is that we could possibly use volatile For making changes to cut for say, you know back porting fixes or we could use back ports for that matter I have a question to the I'm sorry. I don't know your name involved with PVC You mentioned that the daily installer was broken a certain percentage of the time and I suspect you may knew better than The installer team does quite exactly how often that is Just to get some kind of sense of how far we need to go to make this work roughly high often Would you say that testing is just plain uninstallable right now? Yes, I Think a lot of the time it wasn't just that the Debian installer was Broke Wouldn't install it's to find a map It was difficult for me to guide users through the process of finding the matching boot Dot image dot G zip and the ISO which is which is kind of just weren't there Yeah, I mean it's kind of just the fact that like we've said di does rot and it can be hard for users to find the right one And if we have a release with a nice website that says here it is that solves a lot of issues Yeah, build against a stable thing We're kind of getting a little on time and I unfortunately have an appointment after this So I don't know how many could I just get a show of hands how many more people have to have questions Okay, let's do some more Maybe before the end you should just comment on how to go forward. Yeah, totally Yeah, absolutely. I mean the thing that I'm seeing you know doing CD builds regularly is Trying to get a consistent set When di is basically as you say is watching away You know, which sounds like horrible horrible things in the way of describing obviously people are working on stuff but They could they could be quite a long period where what we currently have in the testing images isn't installable at all because Actually making sure all the packages migrate through and all the you devs are actually in a vaguely usable state It's really quite fragile at the moment So my main worry would be actually trying to keep a usable di going with it going with these cuts right and That's why I'm saying maybe a six-monthly cycle because I think we've managed Pretty consistently to keep that going maybe not quite as well in the past couple of years But I think over the past what how long has it been? While seven years seven eight years We've managed Tolerably well at that and I think you know, I'm really hoping that if we have this cut thing That's going to inject more energy into di into all these other things So that's really part of my hope here Yes next As a comment on Zach's comment in as an alternative to pinning Might it be possible to have some sort of cut proposed upgrades for the small proportion of that 1% that have very vocal users Yeah, that was back to what I was talking about with using either volatile or backpour So just having some repository with a few back ported packages or whatever you need to make cut to make the previous cut work I think it's a good idea So I have one perhaps obvious comment and one concern the obvious comment is that each cut Would need something like a mini release the same kind of thing that you do for a release Would need to be done including creating media the concern that I have is Testing that we get for the next Debian release not the next cut If we bleed away users to the cut we are bleeding users away Partly right and partly wrong it's a two-pronged thing you're bleeding some users away from using The newest testing because they're staying with the old cut you're pulling in a lot of other users hopefully So maybe and it sounds and according to Yuri's You know in Yuri thinks that maybe the people who are using the old version of cut will be desktop users and We have a pretty good idea about the desktop in general We don't have a good idea about the long tail of packages and they'll still be using testing And they'll still get tested more. Yeah, I say about the EPC where I see this going Is that? Often they need the very latest to get it going So cut gives them a safe starting point to perhaps go forward where they would have previously stayed with Lenny and caused All kinds of you know grumbling and whatever about things never working for them So I think I see it as propelling them forward to testing by giving them a margin of safety first Yeah, I think we probably only have time for maybe two or three more questions. I think you should do up up in fact So I think if the target of cut is desktop user that want to have the latest software Couldn't we just learn from other distribution and select a subset of packages that should be in a good state and Use this as a criterion to declare testing as Workable I don't That's I think that's part of what we do But I don't think it's the entire intent of cut to just do that I think we want to do something with cut that no other distribution is doing because otherwise I mean that gives us a competitive advantage to have something that is a rolling release that is usable and So for that for that purpose we want to have to support all the packages as well as we can but we want We especially obviously want to focus on desktop stuff. I don't know if that answers you or not I hope so Releases is not rolling. No, but my annual releases aren't the whole story. That's my point You have final releases you have testing and you try to keep testing more usable than it is now And you and you also advertise the users that hey we have testing. It's usable. Here's how you get that Well What I'd sort what I'd like to do is get a sense If there's anybody brave enough to think that they might want to be involved on a team for cut if I could have some hands I don't recognize all your faces so you can go ahead and raise your hand and they won't Yeah, anybody AJ awesome a lot of people we have six yeah, I'm I'm only like this so Okay, so I saw six or seven hands something like that it sounds like enough people to have a mailing list or a wiki or something and Talk about it and maybe you know flesh out a design doc and maybe start trying to do I think that you can try to benchmark cut by just I mean right now This is a wonderful day because we've just frozen And we actually have on debbie and release a list of every single thing in testing where it's not usable No, no my point is that we've been talking about ways that Testing isn't usable and for most of the day every debbie developer that thinks that testing has an issue with their package It's been frantically posting a debbie and release So that's a great information and it's a good starting point obviously I mean cut zero would be a good thing to do and We could do it by getting the eye working making images making a snapshot and well, hey, the snapshots are almost made So it's a launching point. I think I think all the screen down. I actually wish the release human waited two months, but hey The freeze would probably be like the next to last cut. Yeah, we scroll down That's all I have to say, okay, thank you So if we have a team a possible team I thought I'd go ahead and make a website for it and since that's what Laura's and I are doing I thought I'd put in an advertisement at the end. I hope you don't mind I think I'll wait a minute just to let the advertisement Therefore it is free And unfortunately the bandwidth in here obviously isn't great. Oh, yeah, it's my server. That's it. Which theme do we like this one? No, that one's ugly So my my idea is this will be cut.debian.net Unfortunately, I checked cut.debian.net and it exdomained it and so I can't actually type that in today Once that clears out, I'll fix it. It'll be that so I think we can turn this into a wiki and put up a proposal And make an alias project in a bit which takes a little bit longer. It's a wonderful branchable thing and And make a mailing list and take it from there so I hope that We get a lot of people working on it, and I hope that it happens say