From kde-core-devel Wed Aug 22 17:24:17 2007 From: "Aaron J. Seigo" Date: Wed, 22 Aug 2007 17:24:17 +0000 To: kde-core-devel Subject: Re: clarification on git, central repositories and commit access lists Message-Id: <200708221124.17292.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=118780351314033 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1889148.uy4JZ1TYHG" --nextPart1889148.uy4JZ1TYHG Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 22 August 2007, Thomas Zander wrote: > 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. you're right that it isn't a technical issue. we differ based on this: "aar= on=20 cares about having an agreed upon plan, even a sketch of one, that doesn't= =20 run us the risk of causing community issues and which sounds realistic." as far as i can see, so far we have: =2D people who want will move to using git-svn =2D ??? =2D time passes =2D ??? =2D everyone is using git! i understand that people are still trying to figure out how to transition o= ur=20 one big svn repo to multiple git repos, how to move things gently to git=20 where there is desire to do so, etc... i'm just pointing out that these are= =20 not the only issues to deal with. in fact, these are "just" the implementation detail issues. we have "design= =20 level" issues to figure out, too. no matter what scm we'd be discussing the= se=20 issues would be here. hell, it's not even unique to scm's; splitting bugzil= la=20 out to a new distributed system would come with similar (if not as=20 development critical) issues. > > 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. this isn't the discussion here at all. we actually agree on this point. it'= s=20 the question of the transition period that is getting sidestepped. > > 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. it matters when "adding ways" comes without reasonably workable means for=20 people working in those different ways to work together. git-svn is being offered as a solution that works when it seems that git-sv= n=20 itself needs a lot of work still. it's also not an answer that mollifies me= =20 since it avoids answering the real question of how do we finally move off o= f=20 svn itself. unless the implication is that we get everyone using git-svn an= d=20 at that point we ditch svn. timelines are also missing. do we target a switch to pure git for no earlie= r=20 than 4.2? (earlier would be a mistake, imho). i think that's important to=20 note so that those moving to git now are aware that they will be committing= =20 to using git-svn for at least that long and don't end up trying to move=20 prematurely and creating unintended chaos.=20 > 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 :) it also means that if people playing with these things drop the ball on the= =20 process, it doesn't hurt things as much. it wouldn't be optimal or even fun/pleasant, but we can live with some=20 extragear apps or even koffice getting screwed for a release or two.=20 realistically we don't have the same luxury for kdelibs/base or most of the= =20 other "core" modules. =2D-=20 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 Trolltech --nextPart1889148.uy4JZ1TYHG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGzHFB1rcusafx20MRAjaVAJwPhtagMiFxO90O17ClnoMn369bnACgrEwd 39/lljyA2x6oZiXRBfQ7iOQ= =ngHC -----END PGP SIGNATURE----- --nextPart1889148.uy4JZ1TYHG--