Re: "Forking is a Feature" reactions?

On 15/09/2010 19:32, Tony Finch wrote:
> On Wed, 15 Sep 2010, Santiago Gala wrote:
>> On Wed, Sep 15, 2010 at 8:04 AM, Dirk-Willem van Gulik
>> <dirkx-HuV/[email protected]>  wrote:
>>>
>>> Especially as the pattern seems to be conductive to personal
>>> gratification** more than community; and leads to patchcollections
>>> which are the work of love of a single person quite easily. And that
>>> seems to cause fragmentation on an end to end level. I.e. rather than
>>> scratching your own itch - and solving it at a product level - you
>>> create a small alternate reality in which you nullify the issue, in
>>> which you isolate - and then welcome people on your island - but
>>> you've not made the world a slightly easier place. Somehow it feels as
>>> if there is some driver lacking, some positive need to have
>>> communities collaborate.
>>
>> What makes you think that without github people effectively tries to
>> get patches "upstream"? IMO, most of may patches have remained forever
>> in my HD until I deleted or a crash destroyed them.
>
> Right. In my experience a lot of places that deploy open source software
> will fix little niggles (gaps in functionality / integration impedance
> mismatches / whatever) in an expedient manner. They are often reluctant
> to expose their changes because they are too specific or scruffy.

I don't work with a single team of developers, I work with hundreds of 
teams spread across the UK. I mention this because I suspect this gives 
me a broader personal experience of the realities of open source 
***use*** than the majority of folk here.

In my opinion the above statements are absolutely correct. That is, the 
vast majority of local modifications never make it anywhere near project 
maintainers.

GIT does not, and will not, change this on its own - it's a cultural 
issue not a tools issue.

>> Github puts a *public* **indexable** fork one click away. It gives you
>> a backup, so that there is incentive to have all your microchanges up
>> asap.
>
> Right, and it seems to be encouraging people to make their previously
> private patches public. I agree with you that dirkx is observing a problem
> that was always there but previously less visible.

Whilst I agree, I do not believe GIT will help change this. As a project 
maintainer I am unlikely to monitor X branches of my code, I'm going to 
expect people to tell me the patches I should consider. However, in this 
situation GIT does help due to its (allegedly) superior merge handling.

Problem is we are still waiting for the contributor to be confident 
enough to say "look at my code it is great". So we've won almost nothing 
by moving to GIT. Unless...

>> IMO, the main differente between distributed and centralized SCM is that
>> centralized SCM people views my work as "dirty" working copy, while
>> distributed SCM people views it as commits pending integration in my
>> repository...
>
> I have been quite impressed by the culture of code review on the git
> mailing list, and the way they use the tools to improve patchsets before
> integration.

I can't comment on this, but it sounds like you are saying that there 
are cultural models that work. I'd like to hear more about them, but I 
guess getting through the noise of a discussion on this list will 
discourage anyone with the necessary experience spending time on trying 
to communicate the lessons to be learned.

Ross