--===============1694228922== Content-Type: multipart/alternative; boundary="----=_Part_12880_29516404.1227638186239" ------=_Part_12880_29516404.1227638186239 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=FCgler 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 ha= ve > 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 t= o > 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 wit= h > the > release management and translation the KDE team then does for you. I'm no= t > aware of any other hard rules, but the policies page on techbase gives mo= re > 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 regul= ar > KDE releases, rules for that apply. Basically, you can decide how you wan= t > to > have your release cycle, commit policies etc. Sometimes, people will comm= it > into your code, in almost all cases, those are trivial fixes then. If > something that might raise objections go in, the committer should (as usu= al > 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 appli= es > 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=3D > =3DSaGl > -----END PGP SIGNATURE----- > > ------=_Part_12880_29516404.1227638186239 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
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 per= spective), 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 u= sually gets installed by default, which (i *think*) is not the situation wi= th extragear?
what do you think guys?
 
thanks,
shie

 
On Tue, Nov 25, 2008 at 6:52 AM, Sebastian K=FCg= ler <sebas@kde.org> wrote:
Hi,

Let me try to shine s= ome light on some of the questions raised in the "should
krusader m= ove into KDE's SVN?" discussion. Please reply to both lists,
krusader-devel@googlegro= ups.com and release-team@kde.or= g

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. (Tra= de-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 choi= ce, however.

* rules
That depends largely on how you'd like t= o 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 y= ou. I'm not
aware of any other hard rules, but the policies page on techbase gives more=
info: ht= tp://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. Basi= cally, you can decide how you want to
have your release cycle, commit po= licies etc. Sometimes, people will commit
into your code, in almost all cases, those are trivial fixes then. If
so= mething that might raise objections go in, the committer should (as usual i= n
KDE) contact the developers before committing. Everybody with a KDE SV= N
account has commit rights though. Basically, you can have Krusader in KDE&#= 39;s
SVN and be as independent as you want.

* advantages:
- le= ss 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 promis= e,
 it's just more likely due to increased visibility)
- can= be released alongside KDE (whereever it ends up, even extragear)
- inte= gration of SVN with bugtracker (Krusader is already using bugs.kde.org,
 right?)
- translation done be KDE translation teams (manpower, con= sistency across
 desktop)
- shows stronger KDE ties, taking a bi= t more advantage of KDE's brand

* disadvantages
- possibly lo= sing 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).

Cheer= s,
--
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 = 0EF9




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linu= x)

iQEcBAABAgAGBQJJLBFDAAoJEGdNh9WRGQ75JKYH/jKSzcbE62uo9bO1xJlo+DFO<= br>f3/mw4Jl1EVfdyUd9IkBSHDEmAGDpLZF0kR8B8uFraUN6FC0X8ZPSbjl+h48r3Ye
xOtWq3NyMGG5K1S8bu3C5Zlgi0P1IkGSdfPbnejmcX/jDoEwfLhP93De+VcJwrgh
EazG+fd= OWwsISPsbd/zG3hYaqSEluIuFtYdOau3FhYLYNxEVzLjraqDV/GLHK+Ey
5PsWYshY8iFH1z= QVkcw0c1KI1ldPTd8iwxtqT0mEwTGaEPfb95pZUd+CnygbIAMi
4Vq++mu/5GCgVFhdCscSV= mCjnYoTGAAI+DzdSLEhM39j+OUwOkew59ON6QtzFCQ=3D
=3DSaGl
-----END PGP SIGNATURE-----


------=_Part_12880_29516404.1227638186239-- --===============1694228922== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team --===============1694228922==--