Maybe kdeutils is a good place, if somebody wants to push krusader. But of course, extragear apps have their own release schedules.
2008/11/26 Jonas Bähr <[EMAIL PROTECTED]>: > Hi, > > Am 25.11.2008 um 19:36 schrieb shie erlich: > >> 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 do also think that it'll be great to move a bit closer to the KDE > Project and to benefit from KDE's infrastructure (translations, review/ > bugtracking, marketing, ... perhaps even mailinglists). > > I feel very comfortable with the SVN Policies on techbase. If they are > really applied by the guys with svn commit access (which would include > us after the move) I don't think we will get in trouble with strangers > doing unwanted code harakiri. > > In my eyes we could move immediately *after* the 2.0.0 release. We > made a first beta for KDE-4 some time ago with a second one on the > door step. I don't want to move in the middle of a release process. > > Since 2.0.0 would be our first KDE-4 release, it would be an > acceptable point to beginn with a blank history. Sebastian, you > mentioned "possibly losing history" as a disadvantage. Does this mean > there is a chance to keep our history? Under which conditions? My svn > knowledge regarding such migrations is limited, but I could only think > of a replay of our repository. This does not really make sense.... > > >> 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? > > I think extragear would be perfectly fine, at least for the beginning. > Some of the most popular KDE apps, like Amarok, live in extragear. > Plus, there we have the maximum of freedom. We can't claim our > independence on the one hand and ask for inclusion in a core module on > the other. > >> what do you think guys? > > I'm all fo a move as soon as 2.0 is out of the door. What does the > rest of the Krew think? > > bye, > Jonas > >> >> 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 | 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----- >> >> >> >> --~--~---------~--~----~------------~-------~--~----~ >> You received this message because you are subscribed to the Google >> Groups "krusader-devel" group. >> To post to this group, send email to [EMAIL PROTECTED] >> To unsubscribe from this group, send email to [EMAIL PROTECTED] >> For more options, visit this group at >> http://groups.google.com/group/krusader-devel?hl=en >> -~----------~----~----~----~------~----~------~--~--- >> > > _______________________________________________ > release-team mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/release-team > _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
