www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: "Forking is a Feature" reactions?
Date Thu, 16 Sep 2010 00:35:45 GMT
----- Original Message ----

> From: Ross Gardler <rgardler@apache.org>
> To: community@apache.org
> Sent: Wed, September 15, 2010 7:18:17 PM
> Subject: 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@webweaving.org>   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.

Sorta begs the question of whether such changes *should* be published.

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

Merging aside, you raise a very good point.  Just about every project I've
ever seen at Apache could use more *attention* - that is the scarce resource
that individuals try hard to protect.  Fortunately it's not a conservative
resource, in that if a project is successful in bringing in new people,
the amount of attention they can bring to the project as a group increases.
It doesn't always work out that way, some committers demand more attention
than others do, but the gist of it is that overall it's better to have
"too many" committers than to not have enough.  That is why the Incubator
likes to see growth and diversity in its podling's committer base.


      

---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org


Mime
View raw message