From kde-core-devel Wed Aug 22 06:45:16 2007 From: Thomas Zander Date: Wed, 22 Aug 2007 06:45:16 +0000 To: kde-core-devel Subject: Re: clarification on git, central repositories and commit access lists Message-Id: <200708220845.16652.zander () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=118776516931648 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1619795.2XvG8d23lq" --nextPart1619795.2XvG8d23lq Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 programming-workflow approach. With that I mean that in KWord I tend to work on a feature by first=20 writing a unit test and committing that. After that I start to implement=20 the feature until it actually passes the unit test and after that I add=20 UIs etc etc etc. In other words; it takes me a week with 30 commits before I finish this=20 new feature. And finish naturally doesn't mean bug-free. During this time I will surely find bugs in other pieces of code, or=20 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= =20 others on the features I publish that git tree. But the small fixes will=20 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=20 upto the release tree. So, what IMOHO you, as a svn user, will end up with is the trunk that=20 doesn't have half finished features that mess everything up. You will=20 still see the current development (mostly) but not the dirty=20 work-in-progress-excuse-the-mess versions. As an example; in Krita we have this excellent GSoC project for color=20 mixing, the author programs in trunk and thus commits everything there.=20 We have had a couple of times when his commits made it hard for others to=20 try out his work. I.e. it was quite broken. I'm all for experimentation=20 so I'm not complaining. But at the same time I do see it as a great=20 opportunity for Git where I can imagine him committing his=20 work-in-progress that is known to create regressions and publish that for=20 other interrested people to see. And only after a week of hacking commit=20 his updated version to the release tree so everyone can enjoy it. =20 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=20 representative version of the software instead of one that is constantly=20 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. = =20 All the workflows you are used to are still there, there just are more=20 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=20 tears down several barriers. For example that people can hack ages and=20 get their stuff into the mainline without being required to actually=20 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=20 community is smart enough to come up with a way of working that allows=20 the community values you mentioned (not quoted here) to stay around while=20 opening up various ways of working that actually leverage that same=20 community more. But, you may be right that we should start at the edges (extragear or=20 KOffice) and experiment there. Showing how it can be done is typically=20 the best way to take away uncertainties :) =2D-=20 Thomas Zander --nextPart1619795.2XvG8d23lq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGy9t8CojCW6H2z/QRAhM+AJ9ColN5oorahn1TMwDzEvXaOa0lngCdGwyX ESrYFInjzYoiXb7Tm4r0fBQ= =jspJ -----END PGP SIGNATURE----- --nextPart1619795.2XvG8d23lq--