on the impending gittness of our source code

[Ben Cooksley]

On Tue, Dec 14, 2010 at 2:21 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> 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

Sysadmin has not reached an internal decision on how to handle team
clones at this time. If you do decide that you want to follow this
path, please let us know so that we can agree internally on how to
handle them.

>
> * 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)

How regular will the merging be? Scripty, etc. only run on main
repositories, not clones, so regular merging will be needed to avoid
issues.

Also, will this allow normal KDE developers to pickup the latest bug
fixes, features, etc as usual? How will this approach handle fixes
done by non-Plasma developers which are trivial into main Plasma
codebase (that which is released)?

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

Rebasing involves force push, which is disabled on git.kde.org for
obvious reasons... if only one person were to do this, they could be
granted permissions to force push to one particular branch, however it
will cause problems for others who may be adding fixes to this branch,
as they will have to throw their checkout of the branch, and any
changes they made to it away.

>
> * 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
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>

Regards,
Ben
KDE Sysadmin