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
<[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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to