[Krusader-devel] Krusader in KDE's SVN

shie erlich shie.erlich at gmail.com
Tue Nov 25 19:36:26 CET 2008

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:

> Hi,
> Let me try to shine some light on some of the questions raised in the
> "should
> 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
> that
> being developed in KDE's SVN, it means you have to comply with KDE's
> release
> schedule. Not true, you can in fact decide that yourself. (Trade-off is
> basically between doing release management yourself and being free to
> decide
> 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,
> however.
> * rules
> That depends largely on how you'd like to release. If you want krusader to
> be
> 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
> the
> 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 more
> info: http://techbase.kde.org/Policies (Note: not all applies to an app
> like
> krusader).
> * control
> You remain in control. If you choose to have Krusader released with regular
> KDE releases, rules for that apply. Basically, you can decide how you want
> to
> have your release cycle, commit policies etc. Sometimes, people will commit
> 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 KDE's
> SVN and be as independent as you want.
> * advantages:
> - less infrastructure maintainance
> - more likely participation of developers that have a KDE SVN account
> already
> - code review, a lot of people follow commits and review patches (no
> promise,
>  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
> bugs.kde.org,
>  right?)
> - translation done be KDE translation teams (manpower, consistency across
>  desktop)
> - 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
> there
> are any questions left I would be happy to answer (as I'm sure that applies
> to
> others as well).
> Cheers,
> --
> sebas
>  http://www.kde.org | http://vizZzion.org <http://vizzzion.org/> |  GPG
> Key ID: 9119 0EF9
> Version: GnuPG v2.0.9 (GNU/Linux)
> f3/mw4Jl1EVfdyUd9IkBSHDEmAGDpLZF0kR8B8uFraUN6FC0X8ZPSbjl+h48r3Ye
> xOtWq3NyMGG5K1S8bu3C5Zlgi0P1IkGSdfPbnejmcX/jDoEwfLhP93De+VcJwrgh
> EazG+fdOWwsISPsbd/zG3hYaqSEluIuFtYdOau3FhYLYNxEVzLjraqDV/GLHK+Ey
> 5PsWYshY8iFH1zQVkcw0c1KI1ldPTd8iwxtqT0mEwTGaEPfb95pZUd+CnygbIAMi
> 4Vq++mu/5GCgVFhdCscSVmCjnYoTGAAI+DzdSLEhM39j+OUwOkew59ON6QtzFCQ=
> =SaGl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/release-team/attachments/20081125/5b8f75e9/attachment-0001.htm 

More information about the release-team mailing list