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

[Aaron J. Seigo]

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?

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. 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

?

our documents should also probably cover how reviewboard and friends can work 
into that workflow as well. i'm also personally somewhat conflicted over how 
to handle bug fixes without getting too complex....

this is all separate from the tools (identity.k.o, etc.) though, and imho 
should probably be a second set of documents on techbase. the git.kde.org 
manual is a decent starting pont for source material for the tools, but we'll 
be starting from scratch for the workflow bits. which makes borrowing pre-
existing work that fits closely with what we need tempting ;)

i'm not sure i have the energy right now to do this (too many other things 
tugging at my sleeves right now), and i am doubly unsure i have enough git 
knowledge to really do a great job of it. i could probably help with the tools 
intro, though; and i wouldn't mind participating, though certainly not taking 
lead on, the workflow bits.

it would be great if we could have a working document (as in: something we are 
actually using, or at least trying to use) for workflow by the time the 
Platform 11 sprint rolls around at the start of June where we could probably 
do some high-bandwidth hammering out of any remaining details, if any. in the 
meantime, as Ian notes, it's likely that kdelibs will start out on day 0 in a 
sort of "what we've always done with svn/cvs, only using git" workflow until 
we have something like this put together.

> Sorry if such documentation already exists and I just didn't find it.

i don't think it does yet .... or at least, i haven't found it either ;)

> For CMake, which moved to git last spring, such a wiki page exists:
> http://www.cmake.org/Wiki/CMake/Git , which was mostly good enough for git

again, thanks for sharing this link ... another bit of useful git-ology added 
to my reading ...

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110120/32734d9f/attachment.sig>