[Krusader-devel] Re: Krusader in KDE's SVN
fundawang at gmail.com
Wed Nov 26 10:50:20 CET 2008
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 <jonas.baehr at web.de>:
> 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?
>> On Tue, Nov 25, 2008 at 6:52 AM, Sebastian Kügler <sebas at kde.org>
>> 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
>> schedule. Not true, you can in fact decide that yourself. (Trade-off
>> 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,
>> * 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
>> 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
>> * control
>> You remain in control. If you choose to have Krusader released with
>> KDE releases, rules for that apply. Basically, you can decide how
>> you want to
>> have your release cycle, commit policies etc. Sometimes, people will
>> 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
>> 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
>> 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
>> - translation done be KDE translation teams (manpower, consistency
>> - 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).
>> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.9 (GNU/Linux)
>> -----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 krusader-devel at googlegroups.com
>> To unsubscribe from this group, send email to krusader-devel+unsubscribe at googlegroups.com
>> For more options, visit this group at http://groups.google.com/group/krusader-devel?hl=en
> release-team mailing list
> release-team at kde.org
More information about the release-team