Just a few thoughts :
Le 20/08/2011 01:40, Matthew Brush a écrit :
On 08/19/2011 03:28 PM, Frank Lanitz wrote:
[...]
P.S. And yes, I still don't see any good reasons for a change as the issues we currently are experiencing, e.g. low an resources for code review will not be solved by any VCS IMHO. I might be wrong, but these are my thoughts. It just doesn't matter how patches are coming in, we need people reviewing them and applying them to main tree. We need people taking care on special parts of Geany as the libsm stuff and other open points and we need less novelistic discussion on mailing list but good usage of wiki. But these are just my 2ct.
With the current way we do things, no one even *can* take care of special parts because only 2 or 3 people have commit access and it's a PITA to contribute by squashing all your commits into a patch and bumping the ML till one of those 2 or 3 people have time to act on it. With a more open/social-type project site, you'll get people making forks to implement a feature, then they'll make a pull request, which others will see and then they will try this feature and test it, and so on. All of this can happen without having to wait for one of the 2 or 3 committers to review and apply a patch.
This point is a bit biased IMHO. Look at e.g. the last example I've seen: the ALSA project (and AFAIK the Linux kernel has a similar workflow). They use their mailing list mostly for sending and reviewing patches, using Git integrated features like format-patch, am etc.
I never tried this workflow in a large scale, but I guess it works well.
And as you said yourself, with Git you can have your own local copies, and you can actually (even already) clone a Git repo and do your stuff in it, and push to the ML (or wherever). The only "problem" is the visibility of the clone, but that's a matter of centralization, which doesn't look that much "D"VCS-ish...
I'm not saying it's not a good idea to use social-whatever way of doing it (though I hit on "social" for this but huh), I just want to say that it's not the only way it can be done efficiently.
I think we also should all read man gitworkflows :) (I still have to do so myself...)
Cheers, Colomban