Re: Re: Fwd: KDE Frameworks Release Cycle
On Tuesday 20 May 2014 07:19:59 Scott Kitterman wrote: On May 20, 2014 4:19:26 AM EDT, Jos Poortvliet jospoortvl...@gmail.com wrote: On Tuesday 20 May 2014 19:07:41 Ben Cooksley wrote: On Tue, May 20, 2014 at 6:04 PM, Kevin Ottens er...@kde.org wrote: snip Now, I think we'll have to agree to disagree on something. You believe there's some rule written in stone somewhere which will make the everyone will pile up backports only the new status quo forever, I say let's try and find out. In the meantime, everyone but the developers will suffer. Yes, and saying no to every proposal won't change that. I believe that the only advantage of the current situation (slow release cycle with a period of 'bugfixes' that go untested) seems to be that it is a known evil: we're lying about them being stable bugfix releases but the They are almost completely bugfix. Every now and then something slips through, but those are mistakes. We (packagers) know exactly how much testing gets done upstream, so we test them before releasing to our users. I already mentioned this once in this thread: such testing has to be done upstream. It is a waste of all distro's time if every distro tests independently the same things, and a bad experience if you miss to test something due to lack of knowledge [1]. I'm quite convince that there is a middle ground which will help the developers and the packagers way. We only have to accept that there will be changes and start to move a little bit. I see here so much possibilities to improve the workflows, but so far all I saw from distro side is change is bad. Let's try a little bit harder to improve the situation :-) Cheers Martin [1] We had pretty bad regressions in KWin once which no distro spotted. From 0 to 10 with 10 being the worst imaginable bug, it scored an 11. signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Fwd: KDE Frameworks Release Cycle
On Wednesday 30 April 2014 11:35:54 Àlex Fiestas wrote: On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote: For non-rolling distros, at some point you have to stop and release. A mix of new features and bug fixes aren't going to be allowed in. We (Kubuntu) have been delivering KDE SC point releases as post-release updates to our users for most (maybe all) KDE4 releases. That's over with KF5. We'll, I guess, have to settle for cherry picking fixes and doing our best. You might not know this but most developers don't do proper testing in the stable branches because the cost of having master and stable environments and doing testing in both branches for each fix is too much, we simply don't have the manpower for that. History has shown this mny times, we have done point releases that were horrible quality-wise because nobody was testing them. The stable branches have virtually no users. Just a note: consider watching David's, Vishesh's and my Akademy talk from last year. I discuss the problem with stable releases in detail and the mess we created in the past. So, I honestly think that if we work together you can do a better work cherry- picking than we can. Also we should develop tools to make your life easier. Actually I think there is nothing wrong with having something like an LTS release which is maintained by the distros. I recently read that Ubuntu picked up maintenance of the Linux Kernel they are using. I think that the same could be done here, just that it might need tighter integration from the distros. E.g. thinking about which version would work well for the next openSUSE and Kubuntu release. Personally from an upstream position I would love to see stronger collaboration between our stakeholders. Also what should be quite obvious: asking the maintainers whether the fixes are backportable should always be possible. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Fwd: KDE Frameworks Release Cycle
Martin Gräßlin wrote: Hello Martin, Actually I think there is nothing wrong with having something like an LTS release which is maintained by the distros. I recently read that This is going to be difficult, to be honest. I can't speak for other distros but in openSUSE *all* the KDE packaging work is 100% volounteer-driven from the community. And there aren't enough of us to handle this properly. I'm guessing that distros with smaller teams would also be negatively impacted. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Fwd: KDE Frameworks Release Cycle
On Wednesday 30 April 2014 12:33:06 Àlex Fiestas wrote: We are all on the same situation and we have to make the best of it. We believe that e can do best if we focus on master and make sure master rocks, it has no regressions etc. Obviously, if we are able to increase the quality of overall frameworks by a more suited development model, the number of bugs goes down and the number of fixes which need to be backported will go down. Which might end this discussion as a non-issue. At least for the frameworks I maintain, I do hope that we will never have to do bug fixes. And that's kind of the case right now already - kwindowsystem 4.x last saw a bug fix in 2012. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Fwd: KDE Frameworks Release Cycle
On Wednesday 30 April 2014 08:24:43 Scott Kitterman wrote: On Wednesday, April 30, 2014 11:35:54 Àlex Fiestas wrote: On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote: For non-rolling distros, at some point you have to stop and release. A mix of new features and bug fixes aren't going to be allowed in. We (Kubuntu) have been delivering KDE SC point releases as post-release updates to our users for most (maybe all) KDE4 releases. That's over with KF5. We'll, I guess, have to settle for cherry picking fixes and doing our best. You might not know this but most developers don't do proper testing in the stable branches because the cost of having master and stable environments and doing testing in both branches for each fix is too much, we simply don't have the manpower for that. History has shown this mny times, we have done point releases that were horrible quality-wise because nobody was testing them. The stable branches have virtually no users. I have been told by you (at UDS) and by many others packagers that our point releases suck, that we introduce huge regressions etc. The above paragraph explains the reason. We have to be realistic here, upstream does NOT have the manpower to maintain more than one release. So, I honestly think that if we work together you can do a better work cherry- picking than we can. Also we should develop tools to make your life easier. We test the point releases before we ship them to end users. Sometimes we find regressions. It happens. I'm pretty sure I didn't say the suck. I've invested a lot of hours of my free time both getting approval to ship them post release and packaging them as well. I wouldn't have done that if I thought they sucked. I'm well aware of the amount of testing the stable branches get. That's why we do the testing we do before we ship them. I can't recall the last time we had end user complaints of a regression after a stable update has been released to end users. I think the best tool to make our life easier would be maintenance branches. If you only want to have one every 3 - 6 KF5 releases, fine. I know that this is a change from how it is right now: but wouldn't it be better if those who are interested do these branches? Let's face it whatever we do upstream cannot suite all of our downstreams at the same time. And please remember: this is only about frameworks, not about the applications or the workspace. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Fwd: KDE Frameworks Release Cycle
On Wednesday 30 April 2014 15:08:55 Raymond Wooninck wrote: On Wednesday 30 April 2014 14:39:31 Martin Gräßlin wrote: I know that this is a change from how it is right now: but wouldn't it be better if those who are interested do these branches? Let's face it whatever we do upstream cannot suite all of our downstreams at the same time. If I take your words literally here, then upstream is not interested in how the distros is packaging KDE. The only point of interest of upstream is to deliver new releases. This is kind of dumping everything to the distros and let them sort things out. I really wonder if this is the release methodology that Frameworks want to apply ? I fail to see how you could have read this into my mail especially considering the other mails where I explained that the new approach is a measure to increase the quality. And please remember: this is only about frameworks, not about the applications or the workspace. But the proposed release cycle for Frameworks could set an example for the others. If this is the way frameworks will follow, what would stop the others from doing exactly the same. Nothing. In the same way nothing would stop them to do that without frameworks doing that. I already shared my plans for a rapid release cycle for KWin during the Wayland port with fellow developers months ago before this discussion for frameworks started. At the same time we decided that for Plasma as the desktop shell it's not suited. Different projects need different release cycles and I'm quite sure that every application will pick the approach which is suited best for them and the stakeholders. We live in a git world and rapid release cycles help to increase the quality. Following this thread I sometimes think people still think in svn. It's quite simple: master is always stable. Period. Code which doesn't have the quality cannot get merged in. Code that doesn't have test coverage cannot get in. We are not switching to a model where everything is lost and distros will have a hard time because the quality sucks and they need to fetch patches from everywhere. We are moving to a model where it should not happen that there are bugfixes needed (yes of course bugs will always happen, but if we fail to get at a point where it doesn't matter for distros, the approach will be wrong). Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Fwd: KDE Frameworks Release Cycle
El Dimarts, 29 d'abril de 2014, a les 15:04:59, Andreas K. Huettel va escriure: Practically this just means that what used to be the stable branch now becomes the distribution patch collection. No, it means that you use the next release as you would do now since it will have the bug you found fixed, or do you guys have a distribution patch collection for firefox? Bad example, our stable users are running Firefox Extended Support Release. (There still is a patch collection, which afaics however mostly targets arch compatibility (alpha, freebsd), library unbundling and build system fixes.) -- Andreas K. Huettel Gentoo Linux developer kde, council signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
