 All right, yeah, so that's me and I looked at our release process and the way we shadow releases and, well, essentially only the way we shadow releases and I think we should do this totally different. Did I get your attention? All right, no, I looked at them and just reconsidered if there's anything we should do different and I didn't find anything but, yes, I'm looking for feedback and just walking through all the things and all the release points and maybe explain a bit how some pieces of the sausage machine work together and why some releases are at which point in time. So who in the audience had ever committed to LibreOffice, has a committed LibreOffice? Okay, so for the other half, the one who ever did a committed LibreOffice, I'm sure wondered what will be the next release where my fix or my patch is in. So for the others, this is exactly explaining the part that these guys probably did when they looked at the release plan to find out when the fix will be released. So this is how LibreOffice releases, it's obvious, huh? So, yeah, maybe I should explain that a little bit more but roughly this is one year of LibreOffice and the piece in the middle is the master branch where we are doing all the main work and breaking stuff and creating new features and do exciting things. And essentially there are like four main points that is we have a release in summer and we have a release in winter and we are starting to cool off breaking things for summer in May and we start to stop breaking things for winter in November and then there are two other points which are the alpha releases which are also tagged and which you can download and then see what the state is in between these releases to give you a feel because otherwise you would be like six months without ever seeing anything of the change except if you would download daily builds. So this is the cycle which is well we're essentially all the main work happens and then I said well we are cooling things off a bit and let's look at this for example for the winter release we're then branching off to a different branch and stuff is happening slower there and this branch is roughly living for about a year in total so it's 11 months in existence. So if you look at the first release of a major version like 5.0.0 this is essentially what happens in winter we had the 4.0 being branched off and all the work was only done here is the only stuff that goes into the new release and then in calendar week this is the better one we're branching off this is the end of November we might have a better two around early December and then in the first weeks of the new year we have the first release candidates and those are the first ones this is important that are built as a release configuration that was important for the last winter release because actually we had a bug that only showed up in the release configuration and we couldn't possibly find it before actually doing a release configuration so it's important to have those builds there too and then at some point we have the final release and we release at the end of January and you see the distances are almost always like two weeks between these points so there's always some time between them so this is the first major release starting and all the change goes in essentially from this point until we have the first release and while this is happening this is also going on the work is already going on for the next bug fix release and those are these so we have bug fix releases shadowed in in certain time steps and the distance is is the first one is very quick as you can see because we find a lot of bugs early on and we fix try to fix them and get them to to use us quickly and the last one is quite a large distance it's 12 weeks but even 12 weeks is enough it's just small enough that if there is some some tricky security thing for example or something which is really we should really be fixing we in most cases don't have to do some special work and do an extra release or something because we can release it on time according to the release schedule and each of these are branched off in the second branch like the first one and the release candidate one that you sometimes see the announcement is essentially done on the date of the branch and the release candidate two is two weeks later and the final release is another week later so that means the whole thing from here from here to here is essentially three weeks so I talked about these different branches and like stuff here is going on madly and people are doing exciting stuff and then we then I said we would do cool things off here and even more here and all that happens is we are using reviews that is you're always committing your stuff on master with very few exceptions and if there's something important to be in a bug fix release you ask it to be backportage to this release branch and for that you need one reviewer and if you want to have it this since we had on this branch like three weeks to to the final you get get it in the in the next release that is happening here and if you really want to have it in the next release that is maybe in two weeks you actually have to get three reviewers to review your code and I don't think we win much I mean we don't find many bugs by that someone reviewing this and saying this is all wrong but there are two things that are happening first of all people are not putting high-risk stuff in there and the other thing is well developers don't like to do this so you really wonder is is this that important that I go through this annoying process and some things are and others are not so one thing that happens especially early on in the release is that we have regressions especially on a new major release and we want to fix them and as I told you these these release candidates betters are roughly two weeks apart from each other and if you have three in a row that means they are four weeks apart what this means is that there are roughly two weeks per qa team and testers can find bugs and then we have two weeks to fix them and for the next release one could wonder shouldn't we just make this longer and not believe this one because the fix is not in there well what would happen then is people would find bugs all the time and we would fix them it couldn't we couldn't can't fix all the bugs discovered in the last week and then we would never release if we always would wait so this is why we have this this two-week cadence of rc's and betters coming up to a release so what does this actually mean for if you're committing your stuff when will it be in the release well if you're committing it on master depends it's between two months and eight months if you're committing here right before the betters is branched off then it's two months until the release for example for winter that would be if you're in late november and you're putting your change in and it goes into the next release it will be released at the end of January just before foster more roughly so this is the ideal case to get your fix in quickly on master if you are unlucky and you are just after branch off and you do that in june well it will take quite some time to the next release so this is essentially the range what happens on master which is why for critical bug fixes you want to have them back ported from here to there or something so if you do that the the range is three weeks to two months and if you have real important fix that needs to go in in the next release absolutely then it's between one week and three weeks oops and then the final thing is why are we not doing this like and this vm forever and do tdf lts releases uh till five years or something well the reason is this thing is turning very quickly and stuff is changing a lot there so if you take something after this has turned five times and tried to backport it to somewhere over there the stuff is looking very different and at least volunteers will not want to do this work so you have to pay information thanks so um if you want to have that uh there are offers from Collaborer Redhead um so comments remarks cloth did i do anything wrong with this opinions yes i will try to make it yes other comments against for example uh i don't think that kills track comparison against firefox and mozilla changed completely and i think they have like months of weeks cycles now so it's rather quick compared to us so i know one distro that does releases every six months um you might have heard of it but um yeah i haven't looked at that too much but i think we are in general with with this we are already rather slow compared to other projects so with the major releases the distance of six months is actually quite a large one if you compare it to other projects and you my opinion is it makes no sense at all to make it bigger just as a thought experiment because once you do that and release only once a year that means that we uh that we that that testers and the people the power users uh are not looking at the product for one year and then uh they are looking at it and everything is broken we have to fix a lot of stuff at the same time as one leap office committer once said um i'm only working on the code i'm not using it that that sometimes happens when you have a code base this big and so many features as leap office does um not every developer can possibly have knowledge about all the the use cases of the product so it's good to have i think the the six month thing is is essentially the limit which we can run we we can leave master unattended to developers after other comments yes statistics or at least that feeling how much do we backport to the lower branches because at least for me each time um one of my thoughts is getting fixed i'm trying to make sure it goes to all relevant branches yeah so at least the the ready release version it's possible to the other ones because some of the distributions seem useless yeah so um i don't have uh heart statistics but uh from the gut feeling like after these branches are very low volume there's not very much going on there these triple reviewed ones they're like maybe a handful 10 to 20 or something even if and the other ones uh you can see actually from the um from the release notes of the updates and they roughly contain around 100 bug fixes each so you have six updates so that's that's essentially your number so at the end you have uh of of one of these when when the tdf version goes out of support you have roughly 600 bug fixes on it that's roughly what i would imagine to be an estimate other comments all right thank you