clarification on git, central repositories and commit access lists
zander at kde.org
Wed Aug 22 07:45:16 BST 2007
On Wednesday 22 August 2007 06:49:55 Aaron J. Seigo wrote:
> > Their git trees (most likely more then one) would be published
> > somewhere for kdepim enthusiasts to follow and develop on, but in the
> > end you'd still need to move the patches that will eventually end up
> > in the final release to subversion.
> which means that between releases they'd have one less person testing
> their code and one less person making the odd fix here and there. i
> track every module and have used HEAD/trunk kdepim for the entirety of
> the kde2 and kde3 series for my day to day use.
> unless their git trees were synced on a very frequent basis with svn
> and unless i could commit to svn and have it sync'd back to one of
> their trees, there's no point in me dealing with running trunk/ apps.
I think we differ in opinion not on a technical but mostly on a
With that I mean that in KWord I tend to work on a feature by first
writing a unit test and committing that. After that I start to implement
the feature until it actually passes the unit test and after that I add
UIs etc etc etc.
In other words; it takes me a week with 30 commits before I finish this
new feature. And finish naturally doesn't mean bug-free.
During this time I will surely find bugs in other pieces of code, or
simple little features to add there. I commit those separately.
All the above goes into one git tree and depending on how much I work with
others on the features I publish that git tree. But the small fixes will
be committed to the 'release' tree (aka svn) as soon as possible.
At the end of the week when my feature is 'done' I will also push that
upto the release tree.
So, what IMOHO you, as a svn user, will end up with is the trunk that
doesn't have half finished features that mess everything up. You will
still see the current development (mostly) but not the dirty
As an example; in Krita we have this excellent GSoC project for color
mixing, the author programs in trunk and thus commits everything there.
We have had a couple of times when his commits made it hard for others to
try out his work. I.e. it was quite broken. I'm all for experimentation
so I'm not complaining. But at the same time I do see it as a great
opportunity for Git where I can imagine him committing his
work-in-progress that is known to create regressions and publish that for
other interrested people to see. And only after a week of hacking commit
his updated version to the release tree so everyone can enjoy it.
leaving the release tree free from major regressions.
> i actually consider eating dogfood to be pretty important.
And I believe that Git actually helps by allowing others to see a more
representative version of the software instead of one that is constantly
> i'd also suggest that there are already enough barriers to contributing
> to kdelibs from application developers that we don't need to widen
> those rifts.
Right, but I don't see how adding ways for people to work widens the rift.
All the workflows you are used to are still there, there just are more
workflow possibilities and thus more ways to get productive.
So, I really don't think it is in any way an extra barrier. It actually
tears down several barriers. For example that people can hack ages and
get their stuff into the mainline without being required to actually
having an svn account. (naturally they can, but they don't have to).
Again, this is about adding ways of working, not about removing old ones.
> now, don't get me wrong. i am very much in favour of moving to
> something better than svn. i think git is a great candidate; perhaps
> even -the- candidate in the mid-term. at the same time, i don't want to
> see that transition cause unnecessary problems.
Neither does anyone else, certainly not me :) And I'm thinking that the
community is smart enough to come up with a way of working that allows
the community values you mentioned (not quoted here) to stay around while
opening up various ways of working that actually leverage that same
But, you may be right that we should start at the edges (extragear or
KOffice) and experiment there. Showing how it can be done is typically
the best way to take away uncertainties :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel