23 Nov
2024
23 Nov
'24
10:04 a.m.
On Pjatnyca 22 Lystopad 7532 18:01:32 deloptes via tde-users wrote:
OK, how many sense in holding all previous binary and source packages? :)
This is normal ... when you are not the "local authority". I actually like
it. It is usually called team work.
I know how teams work, and this one just authoritarian cast tree, when someones on the top
think
they "know roots" and other do not, and for decades they can't fix problems
fixed by experienced
users "without the root knowledges". That is they let for users "eat the
cactus" or drop down this
mess, how do many inexperienced users for that broken KDE3.
And for the "local authority", ALL difficult problems are fixed through hacks!
:)
No idea, but this is the result, when you kind of fork and continue on your
own.
Not fork but stupid re-branding, with constant symbols renaming forward and back, with
changing the
well tested and debugged building system and loss support of old systems, so caused many
hidden and
even visible broken code instead the using stabilisation of the mature code. Also as
changing
habits of the code development and debugging especially for partial fast building, by
implementation cmake, ninja and so on.
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 that waste of time, then you can forget this problem, due to it mostly for Debian 7 and
the old
build 14.0.10. When you want to save disk space, remove old builds, which are not needed
anybody
exactly.
And last versions for old distributions and HW I need, due to work with such hardware,
where you
cannot to install fresh distributions whether in reasons of kernels, or specific modules
to them,
also as through the productivity and do not generating HW garbage.
--
Roman Savochenko
OpenSCADA (http://oscada.org), author and main developer
roman(a)oscada.org, tel:+380679859815
Kamjanske, 51939, Ukraine
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)
I write nothing to TGW right now since there lie tens my previous patches!
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. 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? 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".
I NEVER overpress others, leaving for them the responsibility for their code, which they
can improve
after exploiting the applied code, especially when I don't know deep of the problem
specific, that
is when I don't use this function!
And I was forced to create the my partial fork after my critical for me patches became
ignored, that
I did not choose that!
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.
I have no problem with my "hacks", also as I have no time and wishes to prove
something for
the "local authority"! :)
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.
That is not normal in my 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"
I dealt with the official builds of some Linux distributions, and saw there horde of the
patches to
KDE3, so I can imagine about that "tradition". :)
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? :) 