22 Nov
2024
22 Nov
'24
4:01 p.m.
Roman Savochenko via tde-users wrote:
Raise a ticket in TGW, so that we do not forget it and much better provide a
patch that addresses the issue (not commenting out in the code)
Obviously
This is normal ... when you are not the "local authority". I actually like
it. It is usually called team work.
No idea, but this is the result, when you kind of fork and continue on your
own.
IMO it would be better for all parties that you try doing only temporary
changes and try get them into the main repo, because other wise the work
increases over time. At the end it is your own choice what you do. You are
the "local authority for your work".
If you wish you can write to me in private what issues you have, or post
them here one by one, so that we could discuss.
It would be great if you could contribute, but this includes obeying the
local authority. I am pretty happy with the cooperation with this local
authority. Few things/bugs that were bothering me and I fixed were accepted
without big problems and I learned a lot. I also ported one or two
applications and it also worked quite well. It is just a normal work flow
that you have in every company or open source project. I really do not
understand your frustration, but it is sad to hear disappointment.
You probably never dealt with Gnome/KDE or other projects and their "local
authorities"
not bad, not bad ... I wish I had the time to go through them and move them
(if possible) into the main repo, but unfortunately, I do have very
limitted time. Whenever I find time I will try to pick up one or two and
try to create a patch. Let's see if it works. I do not promise anything.
This is waste of time, disk space (and electricity) I do not have such
systems - in fact it is actually not recommended (it would be forbidden) to
use them for security reasons.
If you have
entry in fstab, you limit udisks - also TDE chooses fstab
entry first. This is correct.
And in fstab you can point any udisks option, where are limits here? :)
May be TDE could be updated so that when you have
udisks in the mount
options, that it would prefer using udisks over fstab.
And do that more unobvious?
There is no problem in building for archived Debian for such support, and
I do that for my project, so proving the developing to environments of
starting the program and some early. :)
Of course there is no problem ... it just makes no sense.
As for the rest Kaffeine for example caused
problems from the start to
present.
Not for me. :)
I am not aware
that some "local authority" did something on purpose to
break something, but honestly this is the reason I never liked or used it
and I stick to kplayer.
When the "local authority" acknowledges all merging request through own
knowledge, it take on self all responsibility from developers for applied
or rejected code, so freezing the changes, which could be reworkered
whether the Author or someone else after testing in the end environment.
Relating to Kaffeine and other, the "local authority" waits that I very
want to place my code to their repository, so I must listen their
instruction and obey without a word even know their are wrong. :)
As far as I
understood tqtinterface was merged into the main code ...
what old compatibility do you mean?
Do you know how many bugs I have fixed during moving to tqtinterface and
cmake, and how many there are leaved hidden issues after potential
building sensitive code with other optimisation options and without some
specific in Autotool?
So, you can see that here —
http://oscada.org/wiki/Special:MyLanguage/User:RomanSavochenko/Open_Source_…
You have to
adjust the headers a bit and
recompile, which the devs are doing anyway for us.
So, where are you already compiled 14.1.3 for Debian 7,8,9? :)