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?
 
thanks,
shie

 
On Tue, Nov 25, 2008 at 6:52 AM, Sebastian Kügler <sebas@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@googlegroups.com and release-team@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 |  GPG Key ID: 9119 0EF9




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iQEcBAABAgAGBQJJLBFDAAoJEGdNh9WRGQ75JKYH/jKSzcbE62uo9bO1xJlo+DFO
f3/mw4Jl1EVfdyUd9IkBSHDEmAGDpLZF0kR8B8uFraUN6FC0X8ZPSbjl+h48r3Ye
xOtWq3NyMGG5K1S8bu3C5Zlgi0P1IkGSdfPbnejmcX/jDoEwfLhP93De+VcJwrgh
EazG+fdOWwsISPsbd/zG3hYaqSEluIuFtYdOau3FhYLYNxEVzLjraqDV/GLHK+Ey
5PsWYshY8iFH1zQVkcw0c1KI1ldPTd8iwxtqT0mEwTGaEPfb95pZUd+CnygbIAMi
4Vq++mu/5GCgVFhdCscSVmCjnYoTGAAI+DzdSLEhM39j+OUwOkew59ON6QtzFCQ=
=SaGl
-----END PGP SIGNATURE-----