On Saturday 01 October 2011 09:15:02 Sven Burmeister wrote: > Am Samstag, 1. Oktober 2011, 07:54:48 schrieb Martin Gräßlin: > > For the bugtracker I think there is a simple solution. > > If a user has 4.x.y and there is a released 4.x.z with z>y don't accept the > > bug report but give the user the information where to request the newer > > version. > > This would mean that downstream cannot fix the bug because they do not know > which fix it is. And of course you have to be sure that the new minor release > fixes it. 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. > > > If a user has a 4.x.y and there is a 4.w.z with w>(x+1) don't accept the bug > > report and give the user the information that he has to update his system > > to a newer version. > > > I doubt we can change the way distributions release their software. As it > > was mentioned in this or another thread: the distributions are always > > interested in the last released version, which is not in sync with what the > > developers are interested in. > > 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? > > 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. Cheers Martin > > > And I don't think redirecting the users to the distro's bugtracker is a > > solution. It just moves the problem. > > That's true since it would be like somebody asking you about e.g. kdepim and > fixing a bug in it. They simply cannot know each piece of software within KDE > but are mainly concerned with packaging and backporting patches. > > Sven > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe > >> <<
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
