Talking to projects to come into the KDE SVN

4 views
Skip to first unread message

Fathi Boudra

unread,
Nov 17, 2008, 6:14:01 AM11/17/08
to krusade...@googlegroups.com
Hi,

dunno if someone read kde-release-team, but as krusader is mentionned,
I'll forward the thread:
http://lists.kde.org/?l=kde-release-team&m=122675748815131&w=2

from Albert Astals Cid to kde-release team list:
[...]
Hi, i was thinking why some quite used KDE-based projects like kdesvn and
krusader are not in the KDE repo.

As far as i know we are VERY open and kdesvn would be an imho welcome addition
to kdesdk and krusader could very well live in extragear.

I'm sure living inside the kde repository has lots of advantages, going from
more exposure, more translators, the ebn, people doing roaming fixes, etc.

Has anyone already talked to them or some other project and can suggest a way
to contact them?

Albert
[...]

cheers,

Fathi

Václav Jůza

unread,
Nov 19, 2008, 3:54:23 PM11/19/08
to krusade...@googlegroups.com, Fathi Boudra
Hi,
I would not object, but since I have been Krusader developer for quite short
time I would keep the decision to the other Krew members.

regards,
Václav

Dne po 17. listopadu 2008 Fathi Boudra napsal(a):

Jonas Bähr

unread,
Nov 19, 2008, 4:32:32 PM11/19/08
to krusade...@googlegroups.com
Hi,

Thanks for forwarding this thread. Some time ago (at least four years,
unfortunately I can't find the mails right now) this has been
discussed already. At this point, the move was rejected, IIRC from our
part; I can't remember the exact reasons though.
Perhaps we should rethink this decision, especially since Krusader's
development slowed down a lot...

One point is the lost of the revision history, but in most cases our
history is not very helpful (comments are most of the time only one-
liners without a real description, many unrelated changes in a single
commit, ...) Perhaps we could use such a move as a new beginning with
better commit messages...

An other thing was the translation. I thing on argument against a move
was that we would loose many of our long term translators who don't
want to become part of KDE's gigantic translation machinery. Dirk,
correct my if I'm wrong.

Can any body else remember other issues from the former discussion?

bye,
Jonas

Dirk Eschler

unread,
Nov 19, 2008, 5:05:07 PM11/19/08
to krusade...@googlegroups.com
On Mittwoch, 19. November 2008, Jonas Bähr wrote:
> Hi,
>
> Thanks for forwarding this thread. Some time ago (at least four years,
> unfortunately I can't find the mails right now) this has been
> discussed already. At this point, the move was rejected, IIRC from our
> part; I can't remember the exact reasons though.
> Perhaps we should rethink this decision, especially since Krusader's
> development slowed down a lot...
>
> One point is the lost of the revision history, but in most cases our
> history is not very helpful (comments are most of the time only one-
> liners without a real description, many unrelated changes in a single
> commit, ...) Perhaps we could use such a move as a new beginning with
> better commit messages...
>
> An other thing was the translation. I thing on argument against a move
> was that we would loose many of our long term translators who don't
> want to become part of KDE's gigantic translation machinery. Dirk,
> correct my if I'm wrong.
>
> Can any body else remember other issues from the former discussion?

Can't remember correctly, i'm getting old. ;-)

I think the main bugger was subversion. It was still young at this time and
the whole development and website scripts depended on cvs. Today we use
subversion and have our own server, so that shouldn't be a problem anymore
(doesn't KDE plan to move to another rcs? :-)).

I'm not sure if we would lose our commit messages. I managed to keep them when
moving from cvs to svn, so svn to svn should be easier - well that's the
theory, i don't know if KDE can or will do an import of our repository.

Translations aren't an issue, in fact i think they would benefit.

Personally i don't object, but i also don't have time to handle anything
regarding this.

bye,
Dirk

--
Dirk Eschler <mailto:dirk.e...@gmx.net>
http://www.krusader.org

Richard/g

unread,
Nov 20, 2008, 12:26:41 AM11/20/08
to krusade...@googlegroups.com
Dirk Eschler escribió:

I tend to agree with Dirk.
Translations would not really be affected.

Krusader would definitely get more traction if it were a
more visible part of KDE. With the change to Kde4, there
is a drop in acceptance of Kde4 which I feel will allow
time for the Krusader project to grow with it. I'm still
using 3.5.x for the stability and preference for the
structure. But, I feel that in time my resistance as well
as that of many others will be overcome and Kde will
continue it's rightful position.

Just my personal opinion as a later adopter. :)

regards,
Richard.

Frank Schoolmeesters

unread,
Nov 20, 2008, 3:32:31 AM11/20/08
to krusade...@googlegroups.com

Hi all,

My "documentation memory" still contains some parts of the previous
kde-extra gear discussion :-)

Actually this is the tirth time that there is a kde extra gear
discussion, but the first time it was in the very early days of
Krusader, when I was not involved in the Krusader project, so about
this first can't tell anything.

The second time it was discussed in september-october 2004,
unfortunately i don't have the e-mails anymore but i can still
remember most of the issues.
IIRC it was me that opened the kde extra gear discussion the second time.
The main reason was to have better (and more) translations (at that
time several translations where unmaintained for to a long time).
The other reason was to have translations of the Krusader documentation.
In the beginning of the discussion "kde" ( i can't remember the name
of the kde person anymore ...) did agree to put only the translation
files into kde repository of kde extra gear, so we had an agreement.
But just before everything started the kde extra gear maintainer ( i
can't remember the name of the kde person anymore ...) added a lot of
new "rules" we need to comply, and than the krew decided to not go to
kde extra gear.
We would need to add the complete source code into kde extra gear.

The big discussion was who controls the KDE repository, and that we
would lose complete control over the Krusader project.
Or have two source code repositories ... which is unmaintanble.

Current developers do know very well the sourcecode.
The problem is that one bugfix of someone who doesn't know well how
all code works, can introduce many other bugs and makes Krusader
unstable.
What if code is added with stuff we don't want to have?
Who makes the "final decission", someone has to do this.

I tend to agree with Jonas that Krusader would benefit from joining
kde extra gear, better visibility, and also because current
development speed is slowed down due to private and professional
obligations. But I would like to have more information about kde extra
gear first.

Basically the main questions is, how the source code is handeled in
kde extra gear, who has commit rights, who has the admin rights, ... ?
It would be nice that someone explains how kde extra gear works.
What are the "rules" we need to comply?
What are the advantages?
What are the disadvantages?
Than we maybe can reconsider joining kde extra gear.


Off topic
Most distrbutions don't add an OFM filemanger when performing an
default installation, wich is very pitty, installing an OFM is the
first action I do after installing any operating system.
One panel filemagers are good for browsing files, but very bad and
very unproductive (tons of waste of time for performing actions) for
managing files. And "two panels view" that some filemanagers do have
is not the same as OFM (many users are not aware of this) where all
the power resides.
http://www.softpanorama.org/OFM/index.shtml
I'm was a Norton Commander user in the very early days and will always
use an OFM :-)
I'm maybe old, but I have still a good memory ;-)

Regards,

Frank

shie erlich

unread,
Nov 21, 2008, 5:49:12 PM11/21/08
to krusade...@googlegroups.com
the main reason was losing control, not only on the source code (everyone can commit) but on release schedule (we had to release in kde's timeline). i'm very sorry for the fact that development slowed down so (i'm one of the main people to blame), but i'm not sure it would help a lot to go to extragear.
having said that, i don't object to that, but i do think it would be wise to check the current "ground rules" of being in extragear before making the move.

shie

shie erlich

unread,
Nov 21, 2008, 8:44:00 PM11/21/08
to krusade...@googlegroups.com
the main reason was losing control, not only on the source code (everyone
can commit) but on release schedule (we had to release in kde's timeline).
i'm very sorry for the fact that development slowed down so (i'm one of the
main people to blame), but i'm not sure it would help a lot to go to
extragear.
having said that, i don't object to that, but i do think it would be wise t=
o

check the current "ground rules" of being in extragear before making the
move.

shie
On Thu, Nov 20, 2008 at 12:32 AM, Frank Schoolmeesters <frank.scho...@gmail.com> wrote:

Csaba Karai

unread,
Dec 8, 2008, 6:00:48 PM12/8/08
to krusader-devel
Shie,

>i'm very sorry for the fact that development slowed down so (i'm one of the
main people to blame)

I also don't work as much on Krusader as I did before. The main reason
of it is that Krusader knows everything, that I need. Sometimes I fix
annoying bugs, and if I am bored I add some new interesting features,
but I don't know what more is really missing from Krusader.

:-)

I know, that there are architectural problems which rarely cause
crash, but I don't have the motivation to fix them because these
crashes occur less than once a month. For example removing the qApp-
>processEvents() calls would be very important, but it would take at
least 2-3 weeks to finish (hard work), and Krusader would crash half a
year instead of once a month...

The only architectural change I'd like to do (only after 2.0 stable),
is to migrate the packers/unpackers to KIO jobs. It is the only
solution for the parallel packing bug and enqueued packing.

Be sure, that if I miss a feature, then I'll implement it as soon as I
can.

Csaba

On nov. 22, 02:44, "shie erlich" <shie.erl...@gmail.com> wrote:
> the main reason was losing control, not only on the source code (everyone
> can commit) but on release schedule (we had to release in kde's timeline).
> i'm very sorry for the fact that development slowed down so (i'm one of the
> main people to blame), but i'm not sure it would help a lot to go to
> extragear.
> having said that, i don't object to that, but i do think it would be wise t=
> o
> check the current "ground rules" of being in extragear before making the
> move.
>
> shie
>
> On Thu, Nov 20, 2008 at 12:32 AM, Frank Schoolmeesters <
>
> frank.schoolmeest...@gmail.com> wrote:
>
> > On Wed, Nov 19, 2008 at 11:05 PM, Dirk Eschler <dirk.esch...@gmx.net>

shie erlich

unread,
Dec 9, 2008, 3:06:54 AM12/9/08
to krusade...@googlegroups.com
well, first of all, i kinda share your opinion. when we started krusader 7 years ago, there was no decent twin-panel gui manager for KDE (i don't remember if there was any at all). coming to think of it, i believe i was the first to use the term twin-panel at all :-)
today (and probably since 1-2 years ago) krusader does all the competition does, and more. it came to do so much stuff, that i can't believe that a lot of the basic design is still there, 7 years later. therefore, when i don't feel that anything is needed, i find it hard to do work "for nothing".
however, for me, it's a bit more than that. i had less and less time for doing anything but work in the last few years (i guess that when you want a career, things like that happen), and honestly, i've been working less with Linux as general, and it doesn't relate to the fact i started working for Microsoft. as a result, i came to situation where i use krusader less, and when i do use it, it does all i need and more.
 
shie

Frank Schoolmeesters

unread,
Dec 9, 2008, 6:44:40 AM12/9/08
to krusade...@googlegroups.com
Hi,

I agree that many many features are available in Krusader.
But if you digg into the forum you will see that there are still many
many great ideas who are not implemented yet.
E.g. I don't like current Krusader's Tab handling, it's to basic, just
compare with TC and click the right-mouse button on a tab and you know
what I'm talking about.
We where the first to have Tabs and TC followed ;) but we never have
improved the Tabs handling afterwards.
Or compare TC with Krusader and you will see that there is still a lot
of room for improvement.
Basically, in our forum several TC users do ask TC features who are
missing in Krusader.

btw. I have less time as well but try to help the project when I have
some spare time

bye,

Frank
Reply all
Reply to author
Forward
0 new messages