reverted commits

[Ralf Habacker]

Havoc Pennington schrieb:
> Hi,
>
> Ralf Habacker wrote:
>> where ?
>> This issue was on the open patch list and was known and discussed
>> several times in the dbus list.
>> see http://lists.freedesktop.org/archives/dbus/2006-July/005081.html
>>      http://lists.freedesktop.org/archives/dbus/2006-August/005531.html
>>
>> My mistake was not to use DBUS_WIN_FIXME, sorry for that.
>
> I probably was thinking of
> https://bugs.freedesktop.org/show_bug.cgi?id=7960
>
> In any case, the point stands and would have come up if the patch were
> posted.
>
>> You have taken this patch and modified it in a manner that all
>> windows bindings are broken 
>
> So fix them, but correctly. The correct fix is not in any way hard.
>
> Or if you think your fix is correct or that the correct fix is
> absurdly hard, then discuss that on the list, but don't just commit
> without me saying OK.
>
> So far on at least two occasions you have said one of my requests was
> an impossible, unreasonable demand and it ended up taking me a few
> hours to do it myself when I got around to it, so I am very skeptical
> of these claims.
>
>> Then we have reverted all our work relating to DBusSocket but the
>> windows builds are still broken because of the changed
>> _dbus_watch_get_fd(). Now we are forced to update all windows
>> bindings which will delay KDE on windows development for several weeks.
>
> By this do you mean it will take several weeks to change the Qt
> bindings to use the new API on Windows? Because I'm pretty sure the
> change will be from:
sorry but you forgot the release time line of qt. It is of course no
problem to patch the sources and to file a request to qt to update their
sources. But it is unclear when this patch will be accepted and when the
next release will be available. Until this point no further dbus release
on windows could be released because they will not work with recent qt.
That is why i suggest to leave the deprecated dbus_watch_get_fd() with
the known behavior at least some releases in the future. unix packagers
does not have this problem because this issue is only limited to
windows. :-(

>> The only thing you tell is that the win32 api isn't declared stable
>> and you request a patch from us, while you have changed.
>
> I've been very clear from the start that a hacked-up Windows port will
> not go in the mainline codebase.
>
> I've just done yet another large chunk of refactoring that should help
> you get a correct, maintainable port in the mainline.
Which is a nice work as i already told about in another mail.
There is a major difference between the qt3/windows port, which was done
by several people and the recent dbus port. For qt we found a stable
complete cross-platform api and the task was only to fill in the
platform related classes. Thats all. On dbus the porting includes the
cross-platform abstraction too which is on a much higher knowledge level
and the needed time wasn't planed by the windows people.
>
> You are, as always, welcome to continue maintaining patches on your own.
>
> The only time my opinion matters is when you want to commit to a
> codebase that I have to deal with long-term. In that case, I am not
> going to allow in broken stuff that can easily be done better.
Very good. This ensures that dbus will have the high quality which is
required as KDE core component.

>> Unfortunally we probably have to tell that we cannot show any KDE
>> application on windows because the core component of KDE, dbus is
>> broken on windows because the maintainer declares the dbus windows
>> api not stable.
>
> The official dbus does not even _have_ a Windows port yet; it has some
> partial patches. So no, it does not have a stable ABI, since it has no
> ABI at all.
>
> You are very welcome to keep a stable ABI in any unofficial patches or
> Windows version of dbus you want to release.
>
> But for the mainline dbus, the Windows port will be done *when*
> someone does the work *fully and correctly*, and *not* before.
Because there are many things changed in the last time, which makes some
requirements obsolate it will be nice to update the definition "stable
ABI" and  "fully and correctly" and how far the current state is far
from it.

Ralf