[Krusader-devel] Re: Krusader in KDE's SVN
frank.schoolmeesters at gmail.com
Tue Nov 25 22:52:25 CET 2008
It would be nice that Krusader (OFM file management in general) could
become more *default* but the problem
is that not many users and distribution creators are not aware that
OFM file management
is the best file management concept that exist IMHO
It combines all the power off: shell, GUI, keybord-shortcuts,
panel-interaction, userscripts, ...
Easy to use by newbies and has all the power for gurus at the same
time (not many programs do have that).
More info about OFM file management at:
I also explained this in the "Talking to projects to come into the KDE
SVN " tread on Krusader-devel.
And so people would re-discover the basic principles of the default
file manager for DOS, the great old Norton Commander.
About the SVN transition, IMHO we are now at the right moment for a move.
We can release current Krusader-SVN trunk as Krusader-2.0.0-beta2
and than start moving the Krusader-SVN code to the KDE servers.
Later on, consider a feature freeze, start maximum debugging, beta-3
release, beta-4 if needed,
and than a first stable Krusader-2.0 for KDE4.
Since Krusader-2.x for KDE4 also compiles on Windows,
it would be wonderful that the KDE project adds Krusader in the
Current Krusader-SVN trunk on Windows should be considered as "alpha"
because it's not yet tested a lot on Windows.
For more testing we need more Windows users and Windows related bug reports.
After that it can become relatively fast considered as "beta".
> (Krusader is already using bugs.kde.org, right?)
Krusader is in bugs.kde.org but it's not used by Krusader project currently ...
It was probably used a very long time ago (it contains Krusader
version numbers 0.75, 0.79, 1.0.2, 1.10 = august 2002).
Krusader uses now the Sourceforge bugtracker
So I suppose we should start using bugs.kde.org again after the move to KDE SVN.
On Tue, Nov 25, 2008 at 7:36 PM, shie erlich <shie.erlich at gmail.com> wrote:
> hi Sebas,
> thanks for the informative mail.
> I, for one, feel confident that the time is right for krusader to move
> closer together with kde.
> i think it has other advantages not mentioned here (mostly from PR
> perspective), but that aside, i would like to know which module krusader
> would be getting into. ideally, i'd like to see krusader in a package that
> usually gets installed by default, which (i *think*) is not the situation
> with extragear?
> what do you think guys?
> On Tue, Nov 25, 2008 at 6:52 AM, Sebastian Kügler <sebas at kde.org> wrote:
>> Let me try to shine some light on some of the questions raised in the
>> krusader move into KDE's SVN?" discussion. Please reply to both lists,
>> krusader-devel at googlegroups.com and release-team at kde.org
>> From the thread held on the krusader list, I'm sensing the misconceptions
>> being developed in KDE's SVN, it means you have to comply with KDE's
>> schedule. Not true, you can in fact decide that yourself. (Trade-off is
>> basically between doing release management yourself and being free to
>> when to release vs. having the KDE release team do it for you, but you
>> have to
>> respect the overall KDE release schedule then). That's your choice,
>> * rules
>> That depends largely on how you'd like to release. If you want krusader to
>> part of KDE releases (be it by means of extragear or some other module),
>> you'll have to respect feature and string freezes. This kind of comes with
>> release management and translation the KDE team then does for you. I'm not
>> aware of any other hard rules, but the policies page on techbase gives
>> info: http://techbase.kde.org/Policies (Note: not all applies to an app
>> * control
>> You remain in control. If you choose to have Krusader released with
>> KDE releases, rules for that apply. Basically, you can decide how you want
>> have your release cycle, commit policies etc. Sometimes, people will
>> into your code, in almost all cases, those are trivial fixes then. If
>> something that might raise objections go in, the committer should (as
>> usual in
>> KDE) contact the developers before committing. Everybody with a KDE SVN
>> account has commit rights though. Basically, you can have Krusader in
>> SVN and be as independent as you want.
>> * advantages:
>> - less infrastructure maintainance
>> - more likely participation of developers that have a KDE SVN account
>> - code review, a lot of people follow commits and review patches (no
>> it's just more likely due to increased visibility)
>> - can be released alongside KDE (whereever it ends up, even extragear)
>> - integration of SVN with bugtracker (Krusader is already using
>> - translation done be KDE translation teams (manpower, consistency across
>> - shows stronger KDE ties, taking a bit more advantage of KDE's brand
>> * disadvantages
>> - possibly losing history
>> - migration effort
>> I for one would be happy to welcome the Krusader team in KDE's SVN. If
>> are any questions left I would be happy to answer (as I'm sure that
>> applies to
>> others as well).
>> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.9 (GNU/Linux)
>> -----END PGP SIGNATURE-----
> You received this message because you are subscribed to the Google Groups
> "krusader-devel" group.
> To post to this group, send email to krusader-devel at googlegroups.com
> To unsubscribe from this group, send email to
> krusader-devel+unsubscribe at googlegroups.com
> For more options, visit this group at
More information about the release-team