Re: PostgreSQL 8.4 development plan

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(at)mielke(dot)cc>