on the impending gittness of our source code

[Aaron J. Seigo]

hey all ...

so. we'll be on git, at least partially, in a little over a week.

short term pragmatisms
===================

it looks quite likely that there is going to be a very awkward time between 
then and 4.6.0 where feature development will happen in git, but bug fixes 
need to be applied to svn. i think it would be good if everyone switched over 
to git when it becomes available, but for as many of us as possible to keep an 
svn checkout around as well so that we can make sure that bug fixes made in 
git make it into svn.

we will need to coordinate on this, though i'm unsure what's the best way 
quite yet. i can't think of a better way than "manually watch commits in git, 
make sure corresponding commits for bugfixes get made to svn". any better 
ideas?


commit messages
==============

i came across this blog entry a little while ago:

http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

and it provides a pretty nice explanation of why it's important to get this 
"right" and how to take advantage of git. essentially:

use a short one line summary, everything else under that. use present tense 
("fix" versus "fixed).

as the FEATURE:, BUG:, IMPROVEMENT: approach has been working out nicely 
(though we need some more discipline in the matter to really get good 
coverage), i'd like to continue this as we move to git. one small change, 
howevr: the "BUG:" entry needs to go in the summary line


development workflow
=================

at the last irc meeting we didn't come to a final conclusion for how we wanted 
to handle branches for development. well, we need to figure this out soon, so 
...

i'd like to see the following principles:

* have a staging repository where bug fixes land and feature branches are 
merged into. this is what most of us will use for day-to-day testing and usage

* use the "main" repository in git.kde.org for release only; staging will get 
merged in on a regular basis (e.g. when we are happy with the results)

* feature branches: if it's more than an hour's work, start a feature branch. 
all feature branches would hang off of the staging repository (or personal 
repos if so desired?)

any objections to the above?

now where i'm still undecided:

* a bug fix branch on the staging branch which would follow staging (probably 
through regular rebasing) where bug fixes would go. these would then be merged 
into staging and when that's proven itself, merged into the release branch. 
alternatively, bug fixes could be done in branches on release and when ready, 
merged into release and then into staging? another alternative would be to do 
with cherrypicking bug fix commits? my main goal is to make merging of 
bugfixes (which may be several commits in total) easy and trouble-free. mixing 
them with features is going to make life harder.

* how to communicate what feature branches there are in progress and the 
status of them. i don't want feature branches to become little caves that our 
work gets lost in, like so many hermits. i'm tempted to put together a shared 
"work board" in a sort-of, kind-of kanban style where we throw up todos, move 
them into various "in progress" states along with the branch they are worked 
in, and move them out when they are complete. it would have to be something 
very easy to use, though, so it actually increases efficiency ;)

thoughts?

-- 
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: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101213/598326bf/attachment.sig