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
signature.asc
Description: This is a digitally signed message part.