KDE git docs for dummies ? WAS: Re: splitting up kdebase in git

Ben Cooksley bcooksley at kde.org
Thu Jan 20 21:14:44 GMT 2011

2011/1/21 Alexander Neundorf <neundorf at kde.org>:
> On Thursday 20 January 2011, Aaron J. Seigo wrote:
>> On Wednesday, January 19, 2011, Alexander Neundorf wrote:
>> > http://community.kde.org/Sysadmin/GitKdeOrgManual looks quite ok for
>> > somebody who knows how to use git for KDE, but not for me.
>> > Can somebody please add a simple step-by-step howto, what I have to do
>> > with identity.kde.org, projects.kde.org and git.kde.org, how the git
>> > push/merge/branching policy is for KDE, etc. If there are existing blog
>> this is, at least to me, two related but separate topics:
>> a) how do i get myself hooked up with all the tools?
>> b) what is the development workflow once i have those tools?
> Yes.
> And anybody who wants to commit needs to get both more or less right right
> from the start.
>> as i understand it:
>> identity.k.o, projects.k.o, reviewboard.k.o, etc. are things you set up
>> once and mostly forget about afterwards. they are the new replacements to
>> the "how do i get an svn account?", "how do get a new svn module?" and
>> "what is the lifecycle of a kde app?"
>> this is mostly about re-working existing documentation, such as:
>>       http://techbase.kde.org/Policies/SVN_Guidelines
>> and it's probably a really good opportunity to try and put it into an order
>> that's even more accessible than what we have right now. a "KDE
>> contributor's primer" on techbase, which is what you seem to be looking for
>> (and something i'd find useful myself as i learn all the new answers, too
>> :)
>> one thing that complicates this is that these tools are to some extent
>> still in development. as needs are discovered and defined, sysadmin is
>> adding capabilities to cover them. the recent addition of
>> http://projects.kde.org/kde_projects.xml is a good example. so the "it's
>> not finished yet, but it's already usable" status does mean it's a little
>> more tricky.
>> the other half of the question is development workflow. and that's even
>> less well defined, as Ian noted. it would be very good, as Ossi noted, to
>> have something that can create some consistency between KDE projects.
>> personally, i think we'll end up with something like this:
>>       http://techbase.kde.org/Policies/Kdelibs_Coding_Style
>> but for git workflow in kdelibs. hopefully then we can encourage as many of
>> KDE projects to adopt it outright or as the core of their own workflow.
>> kdelibs just hasn't had this done for it yet. it's part of the struggle
>> with kdelibs given how distributed and loosely knit the group of people who
>> work kdelibs are.
>> in kde-workspace (and for the parts of kde-runtime we also maintain) we've
>> been discussing how to do things. i love that you shared what CMake has
>> done here as it's a great reference point. thanks for that :) so far, the
>> workflow we've sketched together looks a -lot- like this:
>>       http://public.kitware.com/Wiki/Git/Workflow/Topic
>> i'm fairly tempted to just steal .. er .. borrow, yeah, that's it ..
>> borrow! that from cmake for our needs.
> Would be perfectly fine :-)
> As long as there is no policy defined, I simply try to push/merge to the
> respective master ?
> I also think that really most/all new KDE git repositories should use a common
> workflow.
>> perhaps we could even use it as a
>> starting point for the kdelibs workflow as well.
>> one of the things we haven't worked out yet is how to publish the status of
>> topic/feature branches, which is what this seems to address for CMake:
>>       http://public.kitware.com/Wiki/Git/Workflow/Stage
>> ?
> The git stage for cmake is a set of scripts written by Brad. Not sure it's
> intended to be a long term solution.
> They are thinking about using something else instead ... it has git in the
> name and is a google project.. web thingy... was it gerrit ? Not sure.

Correct, it is Gerrit which is a more git based alternative to Reviewboard.

> Alex


More information about the kde-core-devel mailing list