Am Samstag, 1. Oktober 2011, 09:33:58 schrieb Martin Gräßlin: > Downstreams do not backport fixes. We see that quite clearly. There is no > need to assume that this would change. They also don't know what bugs > exists and what has to be backported. For really critical fixes I do inform > the distros directly (KWin affects all users, that's different for e.g. > products like a game). > > In fact backporting makes our life as upstream even more difficult as the > software does not represent anymore what we think it is and backtraces > might shift the lines making it impossible for us to understand a crash.
Trust me, they want/try to in order to fix bugs without having to ship a minor version update – but they often lack resources/expertise for an app to do so and thus only stick to major bugs. Major in that case can mean crash or really annoying. But if you do not want them to backport fixes, even better, because backporting fixes from one minor to another minor version is a waste of time IMHO. The latter only happens because they are afraid of regressions. > > So as a result the user would not be able to get a fix or the info which > > commit fixes it from bko (bugs.kde.org) and downstream is lost but still > > afraid to release a minor release as official update. > > They don't get that info at the moment either. Do you really think I search > for the duplicate if I know that the issue is resolved? Well, if there is no comment/resolution in a bug report users will feel ignored and are not able to forward that info downstream and hence you get more duplicates and frustrated users. I understand your position, yet the consequences are obvious and you have to blame yourself to a certain extent. > > What about a statement of commitment from KDE devs that regressions > > within minor releases will get fixed before anything else across KDE? > > Fixing a regression is certainly in KDE's interest and downstream could > > be certain that they are not left alone with a regression and might > > consider official updates more often. > > Such a statement would not be worth the pixels to render it. Of course we do > not introduce regressions. But regressions happen without noticing. And it > can happen that we have regressions for several minor releases without > noticing. I remember enough situations where we introduced regressions in a > minor release in KWin without noticing. > > The problem here is that nobody tests branch. Whether we introduce a > regression we notice after the release when people report the bugs. Ok, so what I get from your comments is this: You do not like to get old bug reports ->solution: you want people to update their KDE. You do not mark bugs as duplicate/fixed/mention the fix -> downstream cannot fix it and users feel ignored -> solution: you want people to update You do not like to give a statement that you will first fix regressions, as soon as they are noticed, so that distros can count on minor releases really being bug fix releases and regressions are guaranteed to be fixed ASAP -> solution: more testers. You want more testers to avoid regressions since whoever is currently working on branch, i.e. unreleased code, does not do so well enough. So what's your solution for the latter? If you want people to test your software you have to give them some feedback but since you regard most user feedback as useless and do not state that you are willing to concentrate on regressions if they happen, you will not get any. Where do you want to get the testers from? It would be easy to set-up some repo with daily snapshots of branch but there needs to be an incentive to do so and to use it. Maybe some branch-testing- area in the forums that gets attention if a regression is found, i.e. confirmed by x+1 users over x+1 snapshots. While I can understand that devs would like to concentrate on coding they have to acknowledge that coding within an open source community is different from coding in a company. Devs do it in their free time and testers do so as well. As you cannot demand anything from unpayed coders you cannot do so either from unpayed testers. So the solution is certainly not to act as if one would be working in a company but find a community solution, as e.g. your approach with the forums. And one should not be surprised if no feedback leads to more bad bug reports and frustration rather than less. Sven >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
