[Geany-devel] geany on github; why not?

[Colomban Wendling]

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