Re: Synchronized release schedule for Plasma
Hi, sorry to bring this up again, but I would be in favor of a switching to 2 releases every year. I'd like to add some reasons to do that on the promotional side: 1) In Promo, we are quite stepping up our game in the quality of announcements, to both the website and the release video. We are already a bit stretched out with time, and having more of that to prepare each release would benefit us, especially if we intend - and I think we do - to improve our work even further. 2) We have measured that doing less announcements every year usually gives those more engagement; we'd expect a good rise of that if we switch from 3 to 2 yearly. 3) Finally, we also expect higher engagement if we have more big features to promote. In all the releases I've worked on, I always felt - yes, this is subjective - that the changes were not quite enough to make the user go "wow" (we are generally talking about 2/4 big features each release). Bringing that up by ~50% would help a lot. 4) It is much easier to explain to the users that they are going to get the new features soon in an announcement, if major distributions such as Ubuntu and Kubuntu have the new release ready soon, rather than having to wait months to actually get them. I would also suggest switching to 6 months from a developer point of view, but here I'd prefer to only argue the benefit in the promotional side, adding up to the advantage of synced release frequency with distributions. It doesn't make much sense to be annoyed that your changes do not reach the users in time in a 6 months release cycle, when you currently have to wait about the same amount of time, changing every time, before that version gets picked up by major distributions with most users, as said before. Thanks, Niccolò
Re: Synchronized release schedule for Plasma
Le jeudi, janvier 7, 2021 12:28 PM, niccolo a écrit : > Hi, > sorry to bring this up again, but I would be in favor of a switching to 2 > releases every year. I'd like to add some reasons to do that on the > promotional side: > 1) In Promo, we are quite stepping up our game in the quality of > announcements, to both the website and the release video. We are already a > bit stretched out with time, and having more of that to prepare each release > would benefit us, especially if we intend - and I think we do - to improve > our work even further. I don't agree. The problem is that we are always starting working on an announcement too late. If we were starting more early writing the announcement, it would be easier. > 2) We have measured that doing less announcements every year usually gives > those more engagement; we'd expect a good rise of that if we switch from 3 to > 2 yearly. This is the case for 'release service' announcements. Plasma announcements are getting more and more engagement. Also I'm not sure that having if we were to make 2 announcements instead of 3, the engagement would be more then 50% higher. > 3) Finally, we also expect higher engagement if we have more big features to > promote. In all the releases I've worked on, I always felt - yes, this is > subjective - that the changes were not quite enough to make the user go "wow" > (we are generally talking about 2/4 big features each release). Bringing that > up by ~50% would help a lot. The Plasma 5.21 announcements, I have been working on, is already big enough, so don't worry :) Large set of big features also means more chance of big regressions, big announcements to translate, ... > 4) It is much easier to explain to the users that they are going to get the > new features soon in an announcement, if major distributions such as Ubuntu > and Kubuntu have the new release ready soon, rather than having to wait > months to actually get them. I'm not convinced but I might be biased since I believe full rolling distributions are the only way forward for most end users. > I would also suggest switching to 6 months from a developer point of view, > but here I'd prefer to only argue the benefit in the promotional side, adding > up to the advantage of synced release frequency with distributions. It > doesn't make much sense to be annoyed that your changes do not reach the > users in time in a 6 months release cycle, when you currently have to wait > about the same amount of time, changing every time, before that version gets > picked up by major distributions with most users, as said before. Cheers, Carl > Thanks, > Niccolò > > p.s.: my mail could be arriving with a big delay and duplicated; if so, I'm > sorry, I did some confusion with my different email addresses. > > From "Plasma-devel" plasma-devel-boun...@kde.org > To "plasma-devel" plasma-devel@kde.org > Cc kde-de...@kde.org > Date Tue, 1 Dec 2020 16:01:29 + > Subject Re: Synchronized release schedule for Plasma > > We discussed this in the Plasma meeting on Monday and I'm afraid there's > little appetite in moving to a 6 monthly release or a 3 monthly release. We > did used to have a 3 monthly schedule but that is too tight given the length > of beta and freezes we want to have now. But also 6 monthly feels too long, > for distros that miss the release that become a long time that we have users > on an older release. > > Having said that if there's occasions where we can shift a release a bit to > help distros we're happy to do that. > > Jonathan
Re: Synchronized release schedule for Plasma
Hello, I would like to clarify that Promo has not reached any consensus on whether this would be a good idea for us. With my local promo hat on, I do not think Plasma announcements should be any larger than they are now, as that puts an extra load on translators. Best regards, Ilya Дата: Чт, 07 янв 2021 14:28:50 +0300 niccolo написал(а) Hi, sorry to bring this up again, but I would be in favor of a switching to 2 releases every year. I'd like to add some reasons to do that on the promotional side: 1) In Promo, we are quite stepping up our game in the quality of announcements, to both the website and the release video. We are already a bit stretched out with time, and having more of that to prepare each release would benefit us, especially if we intend - and I think we do - to improve our work even further. 2) We have measured that doing less announcements every year usually gives those more engagement; we'd expect a good rise of that if we switch from 3 to 2 yearly. 3) Finally, we also expect higher engagement if we have more big features to promote. In all the releases I've worked on, I always felt - yes, this is subjective - that the changes were not quite enough to make the user go "wow" (we are generally talking about 2/4 big features each release). Bringing that up by ~50% would help a lot. 4) It is much easier to explain to the users that they are going to get the new features soon in an announcement, if major distributions such as Ubuntu and Kubuntu have the new release ready soon, rather than having to wait months to actually get them. I would also suggest switching to 6 months from a developer point of view, but here I'd prefer to only argue the benefit in the promotional side, adding up to the advantage of synced release frequency with distributions. It doesn't make much sense to be annoyed that your changes do not reach the users in time in a 6 months release cycle, when you currently have to wait about the same amount of time, changing every time, before that version gets picked up by major distributions with most users, as said before. Thanks, Niccolò p.s.: my mail could be arriving with a big delay and duplicated; if so, I'm sorry, I did some confusion with my different email addresses. >From "Plasma-devel" mailto:plasma-devel-boun...@kde.org To "plasma-devel" mailto:plasma-devel@kde.org Cc mailto:kde-de...@kde.org Date Tue, 1 Dec 2020 16:01:29 + Subject Re: Synchronized release schedule for Plasma We discussed this in the Plasma meeting on Monday and I'm afraid there's little appetite in moving to a 6 monthly release or a 3 monthly release. We did used to have a 3 monthly schedule but that is too tight given the length of beta and freezes we want to have now. But also 6 monthly feels too long, for distros that miss the release that become a long time that we have users on an older release. Having said that if there's occasions where we can shift a release a bit to help distros we're happy to do that. Jonathan
Re: Synchronized release schedule for Plasma
Hi, sorry to bring this up again, but I would be in favor of a switching to 2 releases every year. I'd like to add some reasons to do that on the promotional side: 1) In Promo, we are quite stepping up our game in the quality of announcements, to both the website and the release video. We are already a bit stretched out with time, and having more of that to prepare each release would benefit us, especially if we intend - and I think we do - to improve our work even further. 2) We have measured that doing less announcements every year usually gives those more engagement; we'd expect a good rise of that if we switch from 3 to 2 yearly. 3) Finally, we also expect higher engagement if we have more big features to promote. In all the releases I've worked on, I always felt - yes, this is subjective - that the changes were not quite enough to make the user go "wow" (we are generally talking about 2/4 big features each release). Bringing that up by ~50% would help a lot. 4) It is much easier to explain to the users that they are going to get the new features soon in an announcement, if major distributions such as Ubuntu and Kubuntu have the new release ready soon, rather than having to wait months to actually get them. I would also suggest switching to 6 months from a developer point of view, but here I'd prefer to only argue the benefit in the promotional side, adding up to the advantage of synced release frequency with distributions. It doesn't make much sense to be annoyed that your changes do not reach the users in time in a 6 months release cycle, when you currently have to wait about the same amount of time, changing every time, before that version gets picked up by major distributions with most users, as said before. Thanks, Niccolò p.s.: my mail could be arriving with a big delay and duplicated; if so, I'm sorry, I did some confusion with my different email addresses. From "Plasma-devel" plasma-devel-boun...@kde.org To "plasma-devel" plasma-devel@kde.org Cc kde-de...@kde.org Date Tue, 1 Dec 2020 16:01:29 +0000 Subject Re: Synchronized release schedule for Plasma We discussed this in the Plasma meeting on Monday and I'm afraid there's little appetite in moving to a 6 monthly release or a 3 monthly release. We did used to have a 3 monthly schedule but that is too tight given the length of beta and freezes we want to have now. But also 6 monthly feels too long, for distros that miss the release that become a long time that we have users on an older release. Having said that if there's occasions where we can shift a release a bit to help distros we're happy to do that. Jonathan
Re: Synchronized release schedule for Plasma
Hi, Currently there is a KDE Plasma every 4 months. You are suggesting to change that to 6 months, is that correct? Niccolò 2020-11-24 16:07 (GMT+01:00), "Timothée Ravier" said: > Hi KDE/Plasma developers! > Nowadays, Fedora and Kubuntu make new releases twice a year within a week of > each other, with relatively predictable release schedules. > Unfortunately, new KDE/Plasma releases happen a little bit too late for them > to > be included in those distributions in time for the release. Thus the current > version of KDE/Plamsa in both Fedora and Kubuntu is one release behind (at > least on release day). It may or may not be updated after the release. > For the Fedora KDE SIG, we have an issue about this: > https://pagure.io/fedora-kde/SIG/issue/25 > As distribution package maintainers, we would like Plasma developers to > slightly alter the release schedule to align releases with a more distribution > friendly cycle. You could consider shortening one release cycle (and then keep > the 6 month schedule) to align releases. > With this schedule in place, we would also benefit from more beta releases > over > a slightly longer period. They would be packaged into the beta and RC releases > of those distributions thus enabling more pre-release testing. > All of this would benefit both upstream and downstream: > - More pre-release and just released software testing as users test the new > distribution version directly with the KDE beta and fresh stable releases > - More updated and happy users using the latest release > - Less bugs reported against older releases, more bugs reported before the > final stable releases > What do you think? > Thanks! > Timothée Ravier for the Fedora KDE SIG > -- > Timothée Ravier > Red Hat & Fedora CoreOS Engineer > https://www.redhat.com/;>Red Hat > trav...@redhat.com IM: travier >
Re: Synchronized release schedule for Plasma
We discussed this in the Plasma meeting on Monday and I'm afraid there's little appetite in moving to a 6 monthly release or a 3 monthly release. We did used to have a 3 monthly schedule but that is too tight given the length of beta and freezes we want to have now. But also 6 monthly feels too long, for distros that miss the release that become a long time that we have users on an older release. Having said that if there's occasions where we can shift a release a bit to help distros we're happy to do that. Jonathan
Re: Synchronized release schedule for Plasma
On Thu, Nov 26, 2020 at 10:38 PM Neal Gompa wrote: > > On Thu, Nov 26, 2020 at 10:25 AM Aleix Pol wrote: > > > > On Tue, Nov 24, 2020 at 5:10 PM David Edmundson > > wrote: > >>> > >>> As distribution package maintainers, we would like Plasma developers to > >>> slightly alter the release schedule to align releases with a more > >>> distribution friendly cycle. You could consider shortening one release > >>> cycle (and then keep the 6 month schedule) to align releases. > >> > >> > >> We have in the past shuffled things slightly to line up things up with > >> distros on request, particularly LTS releases. We can certainly explore > >> that on a one-off basis. > >> > >> >With this schedule in place, we would also benefit from more beta > >> >releases over a slightly longer period. They would be packaged into the > >> >beta and RC releases of those distributions thus enabling more > >> >pre-release testing. > >> > >> We did have 6 month release cycles in the past. > >> > >> The rationale for moving at the time was twofold: > >> - people rushed in changes towards the feature freeze as otherwise it > >> would be aages till their changes reached users > >> - the more changes we have in a release, the more testing and inevitable > >> regression fixes we need to do, spreading that out should result in things > >> being more stable > >> > >> Initially we did every 3 months (which arguably still aligns) then it > >> slowly slipped to 4. > >> > >> My personal impression is that releases have gotten better as a result of > >> those changes, so I'm hesitant about reverting that decision. > >> > > > > > > Makes sense. With Qt being less of a moving target though, it could make > > sense to reevaluate our cadence though, both because we might start looking > > into the future and because the system we support should not be changing as > > much. > > > > If we don't want to move to 6 months, pulling back from 4 months to 3 > months would make it easier for us to not miss Plasma releases. > > That being said, with Qt6 now being a thing, wouldn't that mean Qt is > more of a moving target again? It will take some time to be able to put together a release that's fully tested against Qt 6. Aleix
Re: Synchronized release schedule for Plasma
On Thu, Nov 26, 2020 at 10:25 AM Aleix Pol wrote: > > On Tue, Nov 24, 2020 at 5:10 PM David Edmundson > wrote: >>> >>> As distribution package maintainers, we would like Plasma developers to >>> slightly alter the release schedule to align releases with a more >>> distribution friendly cycle. You could consider shortening one release >>> cycle (and then keep the 6 month schedule) to align releases. >> >> >> We have in the past shuffled things slightly to line up things up with >> distros on request, particularly LTS releases. We can certainly explore that >> on a one-off basis. >> >> >With this schedule in place, we would also benefit from more beta releases >> >over a slightly longer period. They would be packaged into the beta and RC >> >releases of those distributions thus enabling more pre-release testing. >> >> We did have 6 month release cycles in the past. >> >> The rationale for moving at the time was twofold: >> - people rushed in changes towards the feature freeze as otherwise it would >> be aages till their changes reached users >> - the more changes we have in a release, the more testing and inevitable >> regression fixes we need to do, spreading that out should result in things >> being more stable >> >> Initially we did every 3 months (which arguably still aligns) then it slowly >> slipped to 4. >> >> My personal impression is that releases have gotten better as a result of >> those changes, so I'm hesitant about reverting that decision. >> > > > Makes sense. With Qt being less of a moving target though, it could make > sense to reevaluate our cadence though, both because we might start looking > into the future and because the system we support should not be changing as > much. > If we don't want to move to 6 months, pulling back from 4 months to 3 months would make it easier for us to not miss Plasma releases. That being said, with Qt6 now being a thing, wouldn't that mean Qt is more of a moving target again? -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Synchronized release schedule for Plasma
On Tue, Nov 24, 2020 at 5:10 PM David Edmundson wrote: > As distribution package maintainers, we would like Plasma developers to >> slightly alter the release schedule to align releases with a more >> distribution friendly cycle. You could consider shortening one release >> cycle (and then keep the 6 month schedule) to align releases. >> > > We have in the past shuffled things slightly to line up things up with > distros on request, particularly LTS releases. We can certainly explore > that on a one-off basis. > > >With this schedule in place, we would also benefit from more beta > releases over a slightly longer period. They would be packaged into the > beta and RC releases of those distributions thus enabling more pre-release > testing. > > We did have 6 month release cycles in the past. > > The rationale for moving at the time was twofold: > - people rushed in changes towards the feature freeze as otherwise it > would be aages till their changes reached users > - the more changes we have in a release, the more testing and inevitable > regression fixes we need to do, spreading that out should result in things > being more stable > > Initially we did every 3 months (which arguably still aligns) then it > slowly slipped to 4. > > My personal impression is that releases have gotten better as a result of > those changes, so I'm hesitant about reverting that decision. > > Makes sense. With Qt being less of a moving target though, it could make sense to reevaluate our cadence though, both because we might start looking into the future and because the system we support should not be changing as much. Aleix
Re: Synchronized release schedule for Plasma
> > As distribution package maintainers, we would like Plasma developers to > slightly alter the release schedule to align releases with a more > distribution friendly cycle. You could consider shortening one release > cycle (and then keep the 6 month schedule) to align releases. > We have in the past shuffled things slightly to line up things up with distros on request, particularly LTS releases. We can certainly explore that on a one-off basis. >With this schedule in place, we would also benefit from more beta releases over a slightly longer period. They would be packaged into the beta and RC releases of those distributions thus enabling more pre-release testing. We did have 6 month release cycles in the past. The rationale for moving at the time was twofold: - people rushed in changes towards the feature freeze as otherwise it would be aages till their changes reached users - the more changes we have in a release, the more testing and inevitable regression fixes we need to do, spreading that out should result in things being more stable Initially we did every 3 months (which arguably still aligns) then it slowly slipped to 4. My personal impression is that releases have gotten better as a result of those changes, so I'm hesitant about reverting that decision. David >
