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 <[EMAIL PROTECTED]> 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, > [EMAIL PROTECTED] and [email protected] > > 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 > > > > > -----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----- > >
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
