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.

Alex