on the impending gittness of our source code

[Chani]

On December 14, 2010 02:21:29 Aaron J. Seigo 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?

meh, I don't think this is a big deal; I already have such a setup for 
backporting from git-svn.
we've always had the possibility that people forget to backport; this just 
makes the barrier to backporting slightly higher, so I expect we'll see more 
"please backport" messages. ...hrm, now that I think about it, I haven't seen 
such a message in quite a while :) I guess everyone's learnt to use 
svnbackport. (that or they don't think of it at all..?)

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

why? :)

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

say, after each successful feature merge? or on a weekly basis (unless 
something's too big and needs more stabilizing)?

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

damnit aaron, stop reading my mind ;) I had an email I forgot to send, that 
says essentially the same thing. one repo for official release branches 
(master being a perpetual beta), one for integration and feature branches.

sysadmins: we'd need the ability to easily create and delete branches on the 
staging repo.

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

ah yes, I was unsure about bugs too :P
there are three locations that bugfixes will eventually want to land: release 
master, release branch (eg. 4.5.x), and staging master.

having them on the release repo *might* make it easier to get people to test 
them? I'm not sure. what are the pros and cons of having them on staging?

I *think* that the majority of bugfixes are straightforward, and can be merged 
directly into all three places (or as many as apply). it's the tricky back-
and-forth ones that you'd want a branch for.

I remember quite a while ago, during some git migration talk, qt people were 
talking about how they forward-port instead of backporting bugfixes, and 
seemed to think it was a better workflow. I'd be interested in hearing more 
about that, if anyone can explain it. :)

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

this is why I am very much in favour of having a 'staging' repo where we all 
keep our feature branches. No personal clones. Then I can see all the feature 
branches with a "git branch -r" :)

the only downside is that we'll have to prune it from time to time, so that 
the list is a list of active feature branches, not a full history. (deleting a 
merged branch doesn't delete its commits, so I think that small information 
loss is acceptable)

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

I would love this too. I've tried to use the wiki for it but somehow it just 
seems like too much effort to maintain, and I quickly revert to my private 
text files.

-- 
Chani
http://chani.ca
-------------- 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/20101218/0c4356f8/attachment-0001.sig