Re: Fwd: KDE Frameworks Release Cycle
On Monday 19 May 2014 22:28:27 Scott Kitterman wrote: Speaking as a packager for a distro that's in group #2, I don't see this as any change from your initial proposal. That's correct... You're proposal moves us into group #1 ... which is what I stated I think. Chosen extracts: Going forward I see four options for addressing those packagers: 1) Don't care, which means we're pushing them toward the case 1, they'll release outdated versions with hand picked patches on top; 2) Gain the necessary trust of our downstream to show that our new releases are not less stable than our former bug fix releases; 3) Provide a yearly LTS branch as I've seen proposed; 4) Provide release branches for which we commit backports. [...] So, even though I understand why it wouldn't please packagers, I don't think we should change course overall. So the tactic we'll follow is (1) hoping to get to (2). Indeed, if we don't change course, I expect the distributions will all move to a scheme of backporting. That's unfortunate, but hopefully, we'll manage to gain the required trust to prove that the releases are not less stable than the former bug fix releases So it's not that I don't understand, I completely see what will happen at first. 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. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com 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: Fwd: KDE Frameworks Release Cycle
On Tue, May 20, 2014 at 6:04 PM, Kevin Ottens er...@kde.org wrote: On Monday 19 May 2014 22:28:27 Scott Kitterman wrote: Speaking as a packager for a distro that's in group #2, I don't see this as any change from your initial proposal. That's correct... You're proposal moves us into group #1 ... which is what I stated I think. Chosen extracts: Going forward I see four options for addressing those packagers: 1) Don't care, which means we're pushing them toward the case 1, they'll release outdated versions with hand picked patches on top; 2) Gain the necessary trust of our downstream to show that our new releases are not less stable than our former bug fix releases; 3) Provide a yearly LTS branch as I've seen proposed; 4) Provide release branches for which we commit backports. [...] So, even though I understand why it wouldn't please packagers, I don't think we should change course overall. So the tactic we'll follow is (1) hoping to get to (2). Indeed, if we don't change course, I expect the distributions will all move to a scheme of backporting. That's unfortunate, but hopefully, we'll manage to gain the required trust to prove that the releases are not less stable than the former bug fix releases So it's not that I don't understand, I completely see what will happen at first. And in the meantime, users will get hurt and those of us who do user support will experience severe confusion. We'll have to keep track of which distributions have backported which patches. Your proposal completely destroys the consistency our patch releases previously provided. At the moment, if a user says they're getting a crash in Foo running version 4.Y, everyone else can usually reproduce it. Under your proposal, we'll have users running 5.X who can't reproduce it, while others running 5.X can. A total nightmare. I don't even want to think what it will do to triagers (mission impossible as above), nor do I want to consider how we will handle this for the CI system. As it stands, this proposal is convenient for the KF5 developers, and disregards all the support services. Completely. It will be a complete and unmitigated disaster. 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. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team Regards, Ben Cooksley KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
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 release numbering and lack of new dependencies makes the distro management believe the story. Perhaps, as proposed, going for a cycle where only the January and July releases introduce a major version number and mandatory new dependencies while the other releases are minor-numbered (but otherwise unconstrained in features as long as new dependencies are optional) means we improve on the current situation (minor/bugfix releases don't get tested very well) while also loosing a little (there are new, but optional, dependencies and new features). The packagers can simply go to distro management and call this bugfix releases, as they will (arguably) be more stable than what they currently accept as 'bugfix releases'. And the developers get what they want, too. So after 5.0, 5.0.1 is released with minor features and bugfixes (but no mandatory changes in dependencies at all); which continues until January, when 5.1 comes out, with new dependencies and changes. Consider the potential new API's and components introduced after 5.0 as 'experimental' until January. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Frameworks 5 Beta 2?
Meanwhile, I notice that the release date of May 4th for B2 wasn't attained, or did it just go without a announcement and dot story? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Frameworks 5 Beta 2?
On Tuesday 20 May 2014 10:20:35 Jos Poortvliet wrote: Meanwhile, I notice that the release date of May 4th for B2 wasn't attained, or did it just go without a announcement and dot story? It was published, but indeed no announcement and dot story. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com 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: Fwd: KDE Frameworks Release Cycle
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. No, they aren't perfect, but they are by and large what they claim to be. release numbering and lack of new dependencies makes the distro management believe the story. Perhaps, as proposed, going for a cycle where only the January and July releases introduce a major version number and mandatory new dependencies while the other releases are minor-numbered (but otherwise unconstrained in features as long as new dependencies are optional) means we improve on the current situation (minor/bugfix releases don't get tested very well) while also loosing a little (there are new, but optional, dependencies and new features). The packagers can simply go to distro management and call this bugfix releases, as they will (arguably) be more stable than what they currently accept as 'bugfix releases'. And the developers get what they want, too. So after 5.0, 5.0.1 is released with minor features and bugfixes (but no mandatory changes in dependencies at all); which continues until January, when 5.1 comes out, with new dependencies and changes. Consider the potential new API's and components introduced after 5.0 as 'experimental' until January. So your big plan is we intentionally lie about it? I don't think so. We've pushed nearly every point release to end users throughout the KDE4 cycle. I use them myself. Your characterization of the KDE4 point releases doesn't match my experience. The first time through on this topic, what fraction of packagers said they saw this new release strategy as an improvement? On the kde-core-devel version of this discussion it was claimed the goal of the change was to get KF5 fixes out to app developers sooner so they wouldn't work around KF5 issues in their code. App developers are going to write code that can be deployed. This approach to KF5 releases is, I believe, going to have the opposite effect. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
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: Fwd: KDE Frameworks Release Cycle
On Tuesday, May 20, 2014 13:28:29 Martin Gräßlin wrote: 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 :-) I'm open to discussing change, but so far the change is You're on your own, get over it. Not a lot to discuss in that. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
On Tuesday, May 20, 2014 08:04:59 Kevin Ottens wrote: On Monday 19 May 2014 22:28:27 Scott Kitterman wrote: Speaking as a packager for a distro that's in group #2, I don't see this as any change from your initial proposal. That's correct... You're proposal moves us into group #1 ... which is what I stated I think. Chosen extracts: Going forward I see four options for addressing those packagers: 1) Don't care, which means we're pushing them toward the case 1, they'll release outdated versions with hand picked patches on top; 2) Gain the necessary trust of our downstream to show that our new releases are not less stable than our former bug fix releases; 3) Provide a yearly LTS branch as I've seen proposed; 4) Provide release branches for which we commit backports. [...] So, even though I understand why it wouldn't please packagers, I don't think we should change course overall. So the tactic we'll follow is (1) hoping to get to (2). Indeed, if we don't change course, I expect the distributions will all move to a scheme of backporting. That's unfortunate, but hopefully, we'll manage to gain the required trust to prove that the releases are not less stable than the former bug fix releases So it's not that I don't understand, I completely see what will happen at first. 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. I make no prediction about other distros, only mine. You started this go at the topic by saying that packagers don't understand what developers deal with and developers don't understand what packagers deal with and we had to try and cross that bridge. Given that you're on the developer end of that divide, why do you keep insisting you know better what will happen in my distro that I do? Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
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 So after 5.0, 5.0.1 is released with minor features and bugfixes (but no mandatory changes in dependencies at all); which continues until January, when 5.1 comes out, with new dependencies and changes. Consider the potential new API's and components introduced after 5.0 as 'experimental' until January. So your big plan is we intentionally lie about it? I don't think so. Urgh, no let's not do that... I'd rather have people disagreeing than trying to lie or confused them. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com 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: Fwd: KDE Frameworks Release Cycle
On Tuesday 20 May 2014 07:55:26 Scott Kitterman wrote: I'm open to discussing change, but so far the change is You're on your own, get over it. Not a lot to discuss in that. It's not at all the way it's been thought, it is unfortunate if it is perceived that way. Looks like I can't frame and present it properly then. Really the intent is to try something different to foster higher quality output and from there move toward fixing the pain points it might create. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com 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: Fwd: KDE Frameworks Release Cycle
On Tuesday, May 20, 2014 14:07:02 Kevin Ottens wrote: On Tuesday 20 May 2014 07:55:26 Scott Kitterman wrote: I'm open to discussing change, but so far the change is You're on your own, get over it. Not a lot to discuss in that. It's not at all the way it's been thought, it is unfortunate if it is perceived that way. Looks like I can't frame and present it properly then. Really the intent is to try something different to foster higher quality output and from there move toward fixing the pain points it might create. I get that. The problem is the new thing won't be useful to us. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
On Tuesday 20 May 2014 08:00:43 Scott Kitterman wrote: On Tuesday, May 20, 2014 08:04:59 Kevin Ottens wrote: On Monday 19 May 2014 22:28:27 Scott Kitterman wrote: Speaking as a packager for a distro that's in group #2, I don't see this as any change from your initial proposal. That's correct... You're proposal moves us into group #1 ... which is what I stated I think. Chosen extracts: Going forward I see four options for addressing those packagers: 1) Don't care, which means we're pushing them toward the case 1, they'll release outdated versions with hand picked patches on top; 2) Gain the necessary trust of our downstream to show that our new releases are not less stable than our former bug fix releases; 3) Provide a yearly LTS branch as I've seen proposed; 4) Provide release branches for which we commit backports. [...] So, even though I understand why it wouldn't please packagers, I don't think we should change course overall. So the tactic we'll follow is (1) hoping to get to (2). Indeed, if we don't change course, I expect the distributions will all move to a scheme of backporting. That's unfortunate, but hopefully, we'll manage to gain the required trust to prove that the releases are not less stable than the former bug fix releases So it's not that I don't understand, I completely see what will happen at first. 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. I make no prediction about other distros, only mine. You started this go at the topic by saying that packagers don't understand what developers deal with and developers don't understand what packagers deal with and we had to try and cross that bridge. Given that you're on the developer end of that divide, why do you keep insisting you know better what will happen in my distro that I do? I never said I knew better, actually I'm pretty sure I don't. OTOH I'm sure that polarizing the situation as much isn't going to help figure out the real outcome. Also, I happen to have discussed with other packagers[*] before sending the email of yesterday who have a different opinion than you do, so it can't be labeled as our fate yet. Especially since we generally tend to do a bad job at predictions. Regards. [*] Some of them working on the same distribution than you. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com 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: Fwd: KDE Frameworks Release Cycle
Am Dienstag, 20. Mai 2014, 14.09:18 schrieb Scott Kitterman: Morning Scott On Tuesday, May 20, 2014 14:07:02 Kevin Ottens wrote: On Tuesday 20 May 2014 07:55:26 Scott Kitterman wrote: I'm open to discussing change, but so far the change is You're on your own, get over it. Not a lot to discuss in that. It's not at all the way it's been thought, it is unfortunate if it is perceived that way. Looks like I can't frame and present it properly then. Really the intent is to try something different to foster higher quality output and from there move toward fixing the pain points it might create. I get that. The problem is the new thing won't be useful to us. Ok, fair enough. So what would be your proposal to make it better? Thanks a lot for a constructive discussion (and that's not ironic!) Mario ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
On May 20, 2014 8:27:39 AM EDT, Kevin Ottens er...@kde.org wrote: On Tuesday 20 May 2014 08:00:43 Scott Kitterman wrote: On Tuesday, May 20, 2014 08:04:59 Kevin Ottens wrote: On Monday 19 May 2014 22:28:27 Scott Kitterman wrote: Speaking as a packager for a distro that's in group #2, I don't see this as any change from your initial proposal. That's correct... You're proposal moves us into group #1 ... which is what I stated I think. Chosen extracts: Going forward I see four options for addressing those packagers: 1) Don't care, which means we're pushing them toward the case 1, they'll release outdated versions with hand picked patches on top; 2) Gain the necessary trust of our downstream to show that our new releases are not less stable than our former bug fix releases; 3) Provide a yearly LTS branch as I've seen proposed; 4) Provide release branches for which we commit backports. [...] So, even though I understand why it wouldn't please packagers, I don't think we should change course overall. So the tactic we'll follow is (1) hoping to get to (2). Indeed, if we don't change course, I expect the distributions will all move to a scheme of backporting. That's unfortunate, but hopefully, we'll manage to gain the required trust to prove that the releases are not less stable than the former bug fix releases So it's not that I don't understand, I completely see what will happen at first. 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. I make no prediction about other distros, only mine. You started this go at the topic by saying that packagers don't understand what developers deal with and developers don't understand what packagers deal with and we had to try and cross that bridge. Given that you're on the developer end of that divide, why do you keep insisting you know better what will happen in my distro that I do? I never said I knew better, actually I'm pretty sure I don't. OTOH I'm sure that polarizing the situation as much isn't going to help figure out the real outcome. That's how it comes across to me. There was a lot of negative feedback the first time and the reaction to that comes across to me as a patronizing repetition of the initial proposal wrapped up in IMO unfounded assurances that it would be fine. Sorry if it comes across as harsh. I actually waited half a day to calm down before I replied. Also, I happen to have discussed with other packagers[*] before sending the email of yesterday who have a different opinion than you do, so it can't be labeled as our fate yet. Especially since we generally tend to do a bad job at predictions. Regards. [*] Some of them working on the same distribution than you. None of them are the one that did the work to get our current approval to ship KDE point releases post-release. If they feel differently though they should say so publicly. I'm not going to argue with anonymous theories channeled through you (or through anyone). Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
On Tuesday 20 May 2014 08:52:39 Scott Kitterman wrote: That's how it comes across to me. There was a lot of negative feedback the first time and the reaction to that comes across to me as a patronizing repetition of the initial proposal wrapped up in IMO unfounded assurances that it would be fine. Then there's likely no possible discussion at that point. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com 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: Fwd: KDE Frameworks Release Cycle
On May 20, 2014 8:52:30 AM EDT, Mario Fux kde...@unormal.org wrote: Am Dienstag, 20. Mai 2014, 14.09:18 schrieb Scott Kitterman: Morning Scott On Tuesday, May 20, 2014 14:07:02 Kevin Ottens wrote: On Tuesday 20 May 2014 07:55:26 Scott Kitterman wrote: I'm open to discussing change, but so far the change is You're on your own, get over it. Not a lot to discuss in that. It's not at all the way it's been thought, it is unfortunate if it is perceived that way. Looks like I can't frame and present it properly then. Really the intent is to try something different to foster higher quality output and from there move toward fixing the pain points it might create. I get that. The problem is the new thing won't be useful to us. Ok, fair enough. So what would be your proposal to make it better? Thanks a lot for a constructive discussion (and that's not ironic!) This or something very like it was already suggested by someone else, so I'm not claiming this as my idea, but I think a reasonable compromise would be something like: - Monthly feature releases as proposed. - Select one release every 6 months as long term support (I'd suggest March/September) which has a stable branch. - Developers backport safe fixes to the stable branch. - For complex changes the can't safely be applied to the stable branch, a new branch off of stable is created and the developer issues a call for testing (maybe on this list). If testing succeeds, it gets merged back to stable. - Updates to the stable branch get released monthly at the same time as the monthly feature release. Something like that. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
hi ... it would be interesting to see a true cost/benefit analysis using real data of the benefits of the monthly bug fix releases. in support of what Kevin is going after here: the monthly bugfix releases sound awesome on paper, but they don't always work. i've seen significant regressions in recent releases due to patches being backported with poor judgment, resulting in bug reports by users. this has also happen less recently, of course. it just simply _happens_. the monthly bug fix releases are NOT a panacea, they are just better than not doing anything at all for N months. this is something everyone ought to accept: it is reality. there is, however, a high rate of success for backported patches. the overwhelming majority do what they are supposed to. that is also reality. the actually interesting question is how many of those successful patches are so important that users need them now versus 6 months from now, and how bad regressions are. those measurements are not objective. they require some values to be expressed and applied to them. some may not think the odd regression is a big deal, some might think it is THE thing to avoid. quantity, quality, flow, reliability, etc... keeping in mind that this thread is not about Plasma or any of the KDE applications, the expectations and goals of the *Frameworks* developers _and_ users (app devs) are probably unique in this case. the Frameworks team would probably do everyone a favor by clearly stating their goals in terms of stability expectations and rate of change so we know how to weight the different outcomes that happen. anyways, on to Scott's (re-)proposal: On Tuesday, May 20, 2014 09:45:36 Scott Kitterman wrote: This or something very like it was already suggested by someone else, so I'm not claiming this as my idea, but I think a reasonable compromise would be something like: - Monthly feature releases as proposed. - Select one release every 6 months as long term support (I'd suggest March/September) which has a stable branch. has anyone sat down and done a proper best time measurement? 6 months is thrown out there probably because we know 6 months and certain distributions have made it a popular number. but what is the *actual* largest number that reaches as many distribution releases as possible? in any case, having long term stability branches is not the worst thing in the world imho and is a good idea. it's not popular amongst many developers, admittedly. i tried to advocate for this for both kdelibs 4.7 and kde- workspace 4.11 .. the former was rejected, and problems ensued; the latter was adopted and it has worked very nicely, though there was some degree of skepticism. so that's a hump to climb over which Scott is evidently hitting. as a user, i'd love to see such stable branches, fwiw, and i'd be just happy with a single new kdelibs long term release every year. 6 months feels a bit like luxury. (long: you keep using that word, but i don't think it means what you think it means. ;) - Developers backport safe fixes to the stable branch. this is a critical issue. not enough developers who backport are able to accurately judge this consistently enough. many reasons exist for this (tooling, testing, experience, blah blah) but reasons are just reasons - if we rely on developers to backport safe fixes, it's going to break (because it does already) and that will defeat one aspect of what Kevin is trying to achieve: higher quality there are ways around this, however! it is not uncommon in other projects for people to own a long term branch and only they merge in patches. period. that person needs to be disciplined (so they don't just become a rubber-stamp bureaucrat), but this is one area where having a bottleneck is actually good: you don't WANT lots of changes. you WANT a slow rate of change. you WANT every change to be justified. for it to work that person(s) needs to be able to say no. they also need to be allowed to say no. if they won't say no when necessary, there is no point in having them there. if developers submitting patches rebel whenever they do say no, then there is no point in having them there. that implies the need for an explicitly defined position and probably have an initial public show of hands vote of support by the existing contributors to Frameworks to grant the position legitimacy. i honestly don't see having a long term branch working otherwise. and perhaps that's were some of the tension arises: one party is asking for something that doesn't work but which they feel a need for, and the other party doesn't want to do something that doesn't work ;) - For complex changes the can't safely be applied to the stable branch, a ALL complex changes are in the set of can't safely be applied new branch off of stable is created and the developer issues a call for testing (maybe on this list). If testing succeeds, it gets merged back to stable.
Re: Fwd: KDE Frameworks Release Cycle
Hi, 2014-05-20 13:19 GMT+02:00 Scott Kitterman: We've pushed nearly every point release to end users throughout the KDE4 cycle. I use them myself. Your characterization of the KDE4 point releases doesn't match my experience. here is just one recent example, where someone pushed a commit to the KDE/4.13 which seemed to work fine for him: https://git.reviewboard.kde.org/r/117044/ The next ones to test the patch were the users who upgraded from KDE SC 4.13.0 to 4.13.1, and then noticed this regression: https://bugs.kde.org/show_bug.cgi?id=334776 I know that such things do not happen in every bug fix update, of course. Most of the time, they do improve the user experience considerably, but there is always the risk that things turn out pretty badly for some users. Nevertheless, I still appreciate the possibility to release regular bug fix updates, and I am very grateful that the packagers invest a large amount of time each month to help with that! Please let us all acknowledge and appreciate that everyone here tries to provide a great KDE experience to users, and possibly make it even better in the future. * Packagers appreciate the possibility to ship monthly bug fix updates to users, and I guess that most of us understand and appreciate that. On the other hand, they cannot ship updates that contain anything but bug fixes - I think that we just have to acknowledge that this is due to distro policies that will not be changed for KDE Frameworks. * Frameworks developers would like to provide regular updates to users which are tested well (in order to prevent annoying regressions which ruin the user experience, and possibly, also KDE's reputation). It has become obvious that the initial 1-month release cycle plan might not work out fully as expected due to distro policies which will not change. But in any case, even if a distro would not update the KF5 version that it shipped with initially at all, then at least we would prevent that code which has seen little to no testing appears on user's machines, and this is a good thing. And if we can find ways to improve that, then it's even better. Thanks and best regards, Frank ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Frameworks 5 Beta 2?
On Tuesday 20 May 2014 11:30:54 Kevin Ottens wrote: On Tuesday 20 May 2014 10:20:35 Jos Poortvliet wrote: Meanwhile, I notice that the release date of May 4th for B2 wasn't attained, or did it just go without a announcement and dot story? It was published, but indeed no announcement and dot story. Why did this happen? Cheers, Albert Regards. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
On May 20, 2014 10:38:54 AM EDT, Aaron J. Seigo ase...@kde.org wrote: hi ... it would be interesting to see a true cost/benefit analysis using real data of the benefits of the monthly bug fix releases. It would. I've no idea how to do it. My impression is providing them is popular with our users. At one point it was popular with KDE developers too. in support of what Kevin is going after here: the monthly bugfix releases sound awesome on paper, but they don't always work. i've seen significant regressions in recent releases due to patches being backported with poor judgment, resulting in bug reports by users. this has also happen less recently, of course. it just simply _happens_. the monthly bug fix releases are NOT a panacea, they are just better than not doing anything at all for N months. this is something everyone ought to accept: it is reality. Agreed. there is, however, a high rate of success for backported patches. the overwhelming majority do what they are supposed to. that is also reality. the actually interesting question is how many of those successful patches are so important that users need them now versus 6 months from now, and how bad regressions are. those measurements are not objective. they require some values to be expressed and applied to them. some may not think the odd regression is a big deal, some might think it is THE thing to avoid. quantity, quality, flow, reliability, etc... For Kubuntu, we're in the no regressions camp. After one of our releases we consider we have a contract with our users not to break stuff that's working. keeping in mind that this thread is not about Plasma or any of the KDE applications, the expectations and goals of the *Frameworks* developers _and_ users (app devs) are probably unique in this case. It doesn't do app devs any good to use releases that their users aren't going to have. the Frameworks team would probably do everyone a favor by clearly stating their goals in terms of stability expectations and rate of change so we know how to weight the different outcomes that happen. anyways, on to Scott's (re-)proposal: On Tuesday, May 20, 2014 09:45:36 Scott Kitterman wrote: This or something very like it was already suggested by someone else, so I'm not claiming this as my idea, but I think a reasonable compromise would be something like: - Monthly feature releases as proposed. - Select one release every 6 months as long term support (I'd suggest March/September) which has a stable branch. has anyone sat down and done a proper best time measurement? 6 months is thrown out there probably because we know 6 months and certain distributions have made it a popular number. but what is the *actual* largest number that reaches as many distribution releases as possible? For non-rolling distros, 6 months seems like a pretty standard interval. I picked the end of Q1/Q3 just because an end of December release would hit a non-productive time of year for a lot of people. in any case, having long term stability branches is not the worst thing in the world imho and is a good idea. it's not popular amongst many developers, admittedly. i tried to advocate for this for both kdelibs 4.7 and kde- workspace 4.11 .. the former was rejected, and problems ensued; the latter was adopted and it has worked very nicely, though there was some degree of skepticism. so that's a hump to climb over which Scott is evidently hitting. I have this hope months of stable will be an easier sell the TBD until KF5 is out. as a user, i'd love to see such stable branches, fwiw, and i'd be just happy with a single new kdelibs long term release every year. 6 months feels a bit like luxury. (long: you keep using that word, but i don't think it means what you think it means. ;) It's possible there's some irony my word choices. I have zero objections to lots of interim releases if that works for KF5, but having something stable is essential. - Developers backport safe fixes to the stable branch. this is a critical issue. not enough developers who backport are able to accurately judge this consistently enough. many reasons exist for this (tooling, testing, experience, blah blah) but reasons are just reasons - if we rely on developers to backport safe fixes, it's going to break (because it does already) and that will defeat one aspect of what Kevin is trying to achieve: higher quality there are ways around this, however! it is not uncommon in other projects for people to own a long term branch and only they merge in patches. period. that person needs to be disciplined (so they don't just become a rubber-stamp bureaucrat), but this is one area where having a bottleneck is actually good: you don't WANT lots of changes. you WANT a slow rate of change. you WANT every change to be justified. for it to work that person(s) needs to be able to say no. they also need to be allowed to say no. if they won't say no when
Re: Fwd: KDE Frameworks Release Cycle
On May 20, 2014 10:41:04 AM EDT, Frank Reininghaus frank7...@googlemail.com wrote: Hi, 2014-05-20 13:19 GMT+02:00 Scott Kitterman: We've pushed nearly every point release to end users throughout the KDE4 cycle. I use them myself. Your characterization of the KDE4 point releases doesn't match my experience. here is just one recent example, where someone pushed a commit to the KDE/4.13 which seemed to work fine for him: https://git.reviewboard.kde.org/r/117044/ The next ones to test the patch were the users who upgraded from KDE SC 4.13.0 to 4.13.1, and then noticed this regression: https://bugs.kde.org/show_bug.cgi?id=334776 I know that such things do not happen in every bug fix update, of course. Most of the time, they do improve the user experience considerably, but there is always the risk that things turn out pretty badly for some users. Nevertheless, I still appreciate the possibility to release regular bug fix updates, and I am very grateful that the packagers invest a large amount of time each month to help with that! Please let us all acknowledge and appreciate that everyone here tries to provide a great KDE experience to users, and possibly make it even better in the future. * Packagers appreciate the possibility to ship monthly bug fix updates to users, and I guess that most of us understand and appreciate that. On the other hand, they cannot ship updates that contain anything but bug fixes - I think that we just have to acknowledge that this is due to distro policies that will not be changed for KDE Frameworks. * Frameworks developers would like to provide regular updates to users which are tested well (in order to prevent annoying regressions which ruin the user experience, and possibly, also KDE's reputation). It has become obvious that the initial 1-month release cycle plan might not work out fully as expected due to distro policies which will not change. But in any case, even if a distro would not update the KF5 version that it shipped with initially at all, then at least we would prevent that code which has seen little to no testing appears on user's machines, and this is a good thing. And if we can find ways to improve that, then it's even better. And please note that the regression was found in our pre-release (to end users) testing process and when all Kubuntu users get 4.13.1 they won't have that issue. This is an example of of testing process at work. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
On Tue, May 20, 2014 16:38:54 Aaron J. Seigo wrote: in support of what Kevin is going after here: the monthly bugfix releases sound awesome on paper, but they don't always work. i've seen significant regressions in recent releases due to patches being backported with poor judgment, resulting in bug reports by users. And these are backports done by KDE devs, no? Imagine how bad the regressions might be if backports are done only by downstream distributions with far less experience with the codebase. this has also happen less recently, of course. it just simply _happens_. This is true, stuff happens. But we have to think about it probabilistically. I don't think anyone is asking for an ironclad solution, simply a give us the less bad workable option. Even the packagers' no new features policies can be considered as a 'least- bad' course of action: I don't think anyone would oppose minor new features that can be genuinely, 100% guaranteed to cause no additional bugs or regressions whatsoever. But of course, experience has shown that such guarantees are lies. Taken statistically over the mass of commits they package, most of the non-rolling distros have converged on bugfix-only policies as they provide the best tradeoff of fixing bugs and regressions given limited testing and QA budgets and timelines for all parties concerned. Even rolling distros still tend to have varying concepts of branch stability as they work to integrate upstream releases. E.g. my Gentoo box only marked the 4.12 branch as stable the other day, when we were already up to 4.12.5. the monthly bug fix releases are NOT a panacea, they are just better than not doing anything at all for N months. this is something everyone ought to accept: it is reality. Well hey, I think we're now all in agreement. :) there is, however, a high rate of success for backported patches. the overwhelming majority do what they are supposed to. that is also reality. Yup. the actually interesting question is how many of those successful patches are so important that users need them now versus 6 months from now, and how bad regressions are. those measurements are not objective. they require some values to be expressed and applied to them. some may not think the odd regression is a big deal, some might think it is THE thing to avoid. quantity, quality, flow, reliability, etc... Agreed. the Frameworks team would probably do everyone a favor by clearly stating their goals in terms of stability expectations and rate of change so we know how to weight the different outcomes that happen. Honestly I think they've been fairly clear. The issue is that there are big flaws in the current KDE4 development model, which the current proposal is trying to address. As it stands now, to get a bugfix to the users quickly you have to develop a bugfix and commit against 2 (sometimes 3) different branches, and to get a new feature to the users takes ~6 months in the average case. And there are ongoing developer-time issues trying to do good testing of backported patches. The proposal aims to fix that by acknowledging the reality that developers are not going to be able to always maintain 2-3 separate development branches (especially with the exploding number of git modules) by moving to a single bugfix+feature development track, but doing rapid iterations to ensure that the Frameworks continue to work well together. I think this has all been clear and explained well enough. But this shift, while being beneficial to the developers, would be very trying to downstream packagers who would have to deal with quite some additional issues of their own if this were to be implemented as proposed (we've already seen how the proposal had to be modified to account for new library dependencies, for instance). in any case, having long term stability branches is not the worst thing in the world imho and is a good idea. it's not popular amongst many developers, admittedly. i tried to advocate for this for both kdelibs 4.7 and kde- workspace 4.11 .. the former was rejected, and problems ensued; the latter was adopted and it has worked very nicely, though there was some degree of skepticism. so that's a hump to climb over which Scott is evidently hitting. I think I proposed this as a compromise as well. Or rather, accept the reality of developer (in-)attention not only by integrating on a single main development branch, but also by concentrating the suck that goes into maintaining a stable branch into one discrete action. At best we would get something like the KDE 4 dev process ideal: The developer with the most experience of the code backports bug fixes which they feel are important (possibly automatically with a commit keyword?), which our distros can all ingest backports from in order to do needed testing (since we're still acknowledging we're **not** able to do more than automatic/CI testing on stable). At worst, we end
Re: Frameworks 5 Beta 2?
On Tuesday 20 May 2014 10:58:01 Albert Astals Cid wrote: On Tuesday 20 May 2014 11:30:54 Kevin Ottens wrote: On Tuesday 20 May 2014 10:20:35 Jos Poortvliet wrote: Meanwhile, I notice that the release date of May 4th for B2 wasn't attained, or did it just go without a announcement and dot story? It was published, but indeed no announcement and dot story. Why did this happen? I think we miss a hand-over from the tarballs are ready to kde-promo can communicate. David, something to add in your release check list? At the end we should notify promo. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com 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
