Re: PostgreSQL 8.4 development plan - Mailing list pgsql-hackers

Fabien COELHO wrote:
> ISTM that a decentralized or distributed SCM for PostgreSQL would be a 
> bad move, however great it would be at branching and merging.  For me 
> it is a philosophy question: if PGSQL is a "common work", then 
> everything should be open and shared, and a centralized systems make 
> sense to embodied this. Even if one can publish one's branch easily 
> with GIT, it's not the same, because it is still a personnal branch 
> somehow.

> I'm not sure I would be proud to use such a stupidly named tool for a 
> "common work". I really do not share Linus humor, and apparent 
> contempt for other people. GIT implements "I want to chose whom I work 
> with, and don't care about the others, and don't ever want to have to 
> look at their ugly patches", or at least it is what I understood from 
> his talk at Google last year. Would this be the future spirit of PG 
> devel? I hope not.

I don't particularly care what it is called or what Linus' intents were. 
Linus has changed his public face on git several times since its 
creation, and I think he is playing with people, manipulating them into 
launching Linux and GIT into open source history. From a political stand 
point, it's about attracting the right sort of people to donate their 
time to your project. Different types of honey attract different types 
of folk. :-)

Your points on centralization are ones that I mostly agree with and 
share. I think it depends on whether you believe that freedom of 
software needs to be enforced, or whether you trust that freedom of 
software will occur on its own as a natural result. Many of us, 
including me, are confused about where we sit on this. It's true that 
people should be encouraged to share their patches with others - as a 
centralized system would do, but should this be enforced on people as a 
centralized system would do?

What happens in PostgreSQL today with CVS?
From a pragmatic standpoint - there is no such thing as a centralized 
system, and there is no such thing as a de-centralized system. People 
work on their patches offline - whether they do this by downloading a 
tar file and patching a local copy, or whether they use CVS to keep up 
to date with HEAD, or whether they employ elaborate mirroring techniques 
to insulate themselves from CVS - they are not doing their actual work 
on a public centralized server. Only their final committed work - 
whatever they choose to commit - reaches the public centralized server. 
In many cases, patches are not welcome on the public centralized server 
because they are either immature, poorly designed, or contain 
unacceptable defects. If I want to work on a piece of PostgreSQL, I 
would probably work in private first, then share my changes on the list, 
and only once I was confident with my change, would I submit it for 
review and possible inclusion. Whether I use GIT or SVN or CVS or 
whether I use my local file system and diff between two directory 
hierarchies, these are merely tools to accomplish my ends. My process is 
basically the same no matter which tool I use. I might be more 
comfortable with one tool, and perhaps my productivity is artificially 
high on one over another because I am unwilling to invest time in 
learning the other - but it's all irrelevant from an open source / free 
software perspective. Some code is shared with the world and some is 
not. One hopes that the valuable code is shared. :-)

Do you have reason to believe that a de-centralized system would hurt 
the future of PostgreSQL? Are there any cases of existing open source 
projects that you are aware of, that have broken due to a switch to a 
de-centralized system? Or is this fear of the unknown? This is an honest 
question - and it is a question I have asked myself.

In my case, I see benefits to a de-centralized system, and benefits to a 
centralized system, but find neither to be compelling in terms of 
choosing a product. My focus has always been on tighter control of the 
changes, reliable merge techniques, and proper change set history 
storage and retrieval. I find it unfortunate that the open source / free 
software community has been unable to produce a "best of all worlds" 
solutions. There is no reason why SVN needs to suck at merging - except 
that the people who cared about merging didn't like the look of SVN and 
moved on to create other tools instead. :-(
From a PostgreSQL perspective - it is probable inevitable that people 
will choose their favourite tool to use, create or re-use existing 
mirror technology to have their way, and the side with the most 
resources will win and have their way in the end. One hopes for an 
overall improvement. :-)

Haha - that's my opinion.

Cheers,
mark

-- 
Mark Mielke <mark@mielke.cc>