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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
