From kde-core-devel Wed Aug 22 17:11:21 2007 From: "Aaron J. Seigo" Date: Wed, 22 Aug 2007 17:11:21 +0000 To: kde-core-devel Subject: Re: clarification on git, central repositories and commit access lists Message-Id: <200708221111.21377.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=118780273403139 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart2024132.pbOoS3Uv2I" --nextPart2024132.pbOoS3Uv2I Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 22 August 2007, you wrote: > On Wednesday 22 August 2007, Aaron J. Seigo wrote: > > 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. > > You can do all of this with git-svn and what I'm suggesting. The whole > idea is that a subgroup of people can use git and the rest of the > developers don't even have to notice that git is being used. ok, so going back to my earlier point which didn't really get answered befo= re=20 the "you can deal with git, dude!" replies: what would be the transition plan? i don't care if it takes people a month to answer that question, but it wou= ld=20 be great if that question doesn't get lost. i'm assuming at some point we'd move from svn to git full-scale[1] and that= 's=20 the part that concerns me. git-svn is not good enough to keep up the "we ca= n=20 use both" facade indefinitely or even for a long period of time.=20 moreover, i'm not sure there's a huge point to trialing git if the intentio= n=20 is to keep svn forever. in fact, i'm pretty sure the goal should be to ditc= h=20 svn at some point in the future. that's the part i'm asking about. we're already seeing issues in kdelibs with those experimenting with git-sv= n=20 accidently reverting commits made to svn, etc... a good scm system should=20 make that hard to do, not easier. so while i see the benefit of trialing=20 things so we can get the knowledge needed for both working in git (e.g.=20 creating HOWTOs and tutorials, finding rough edges for our work flows) as=20 well as for figuring out how to transition from an svn repo to a git based= =20 set of repos from a technical POV, it makes me nervous to embark on that=20 without some idea of which modules will go git at which point and how. one scenario i can see is $FOO_MODULE trying git-svn, finding themselves=20 annoyed at the -svn part and saying, "well, let's just go pure git". better= =20 for the module, worse for kde as a whole. is the plan to slowly move everyone[1] to git-svn then remove svn at that=20 point? is the plan to try git-svn on a (set of) module(s), then convert tha= t=20 module to git and move to the next one(s)? and let's not kid ourselves: because of the popularity of git, i'm already= =20 having the pleasure of dealing with git repos for bits and pieces of kde=20 code. best yet, those repos are not always being sync'd at all with svn.=20 *sigh* so when i said earlier "i won't be impressed" i probably should have= =20 said "i'm increasingly unimpressed". this isn't a theoretical issue for me. and really, for me this isn't a "git or not git" conversation but "how do w= e=20 manage the next scm transition". it's cool that people are thinking about=20 this now as well, since that probably means that by the time 4.1 is out we= =20 can start seriously implementing this stuff as we should have a good plan i= n=20 hand. doing so before 4.1 is out (which should have a quick release cycle,= =20 imho) would not be the wisest thing imho. it would be nice to have at least one release cycle where we can stop=20 fetishizing over our tools and actually write some software, something we=20 haven't really be able to do for a couple of years now thanks to the variou= s=20 changes (svn, cmake, qt4..). moving to git will also likely impact negative= ly=20 the productivity of that given cycle and we will innevitably lose some=20 contributors who can't be bothered to follow us on that transition. all things to think about which go beyond the technical issues of using git. [1] which i think, done right, could be awesome [2] where "everyone" means "everyone possible", which probably translates t= o=20 less than 3/4s of people =3D) =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 --nextPart2024132.pbOoS3Uv2I Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGzG451rcusafx20MRAsP7AJkBSDEVq701eBk2jWPxH/VuGT41VgCfXmKj qEvRD4FxMmpojp1hHWMk/6Y= =2Yo9 -----END PGP SIGNATURE----- --nextPart2024132.pbOoS3Uv2I--