clarification on git, central repositories and commit access lists

[Thomas Zander]

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 
programming-workflow approach.

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 
work-in-progress-excuse-the-mess versions.

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.
I agree.
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 
in flux.

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

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 :)
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070822/021f6124/attachment.sig>