clarification on git, central repositories and commit access lists

[Aaron J. Seigo]

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 before 
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 would 
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 
the part that concerns me. git-svn is not good enough to keep up the "we can 
use both" facade indefinitely or even for a long period of time. 
moreover, i'm not sure there's a huge point to trialing git if the intention 
is to keep svn forever. in fact, i'm pretty sure the goal should be to ditch 
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-svn 
accidently reverting commits made to svn, etc... a good scm system should 
make that hard to do, not easier. so while i see the benefit of trialing 
things so we can get the knowledge needed for both working in git (e.g. 
creating HOWTOs and tutorials, finding rough edges for our work flows) as 
well as for figuring out how to transition from an svn repo to a git based 
set of repos from a technical POV, it makes me nervous to embark on that 
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 
annoyed at the -svn part and saying, "well, let's just go pure git". better 
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 
point? is the plan to try git-svn on a (set of) module(s), then convert that 
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 
having the pleasure of dealing with git repos for bits and pieces of kde 
code. best yet, those repos are not always being sync'd at all with svn. 
*sigh* so when i said earlier "i won't be impressed" i probably should have 
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 we 
manage the next scm transition". it's cool that people are thinking about 
this now as well, since that probably means that by the time 4.1 is out we 
can start seriously implementing this stuff as we should have a good plan in 
hand. doing so before 4.1 is out (which should have a quick release cycle, 
imho) would not be the wisest thing imho.

it would be nice to have at least one release cycle where we can stop 
fetishizing over our tools and actually write some software, something we 
haven't really be able to do for a couple of years now thanks to the various 
changes (svn, cmake, qt4..). moving to git will also likely impact negatively 
the productivity of that given cycle and we will innevitably lose some 
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 to 
less than 3/4s of people =)

-- 
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
-------------- 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/4ee477ad/attachment.sig>