Re: PostgreSQL 8.4 development plan

Tom Lane wrote:
> Mark Mielke <mark(at)mark(dot)mielke(dot)cc> writes:
>
>> In terms of picking an SCM candidate, I don't think "time to install
>> from source" is a legitimate concern. Installing from source is great,
>> but if the package needs to be installed from source, it is not well
>> enough supported by the community to be worth using.
>>
>
> That is 100.0% wrong. Some people want to install from source, and
> some don't have any choice because they are on platforms where there's
> not a prebuilt binary available. I am *not* willing to say that we
> will blow off developers on any platform that some other project is
> choosing not to provide binaries for.
>
> As a fairly well related example, note how CVSup never became the de
> facto standard, because it wasn't portable enough, or at least had made
> the wrong decisions about what to depend on

You are not correct. Different SCM systems have different capabilities.
Value and portability are important factors. Time to install from source
is not. Comparing how easy they are to install from source in terms of
minutes is not a fair assessment of the value they provide nor the
portability of the systems. The numbers you quoted are obviously invalid
as SVN is based very significantly on the APR libraries that Apache is
based on in a well established and successful effort to provide
portability. Would you say that Apache is not a good choice? None of
this proves that SVN is a good choice - but I believe it does prove that
using numbers such as you quoted to draw a conclusion about what is best
for PostgreSQL is a backwards way of thinking about the problem.

GIT is currently poor at portability primarily because it is new, and if
you tried to compile it on Windows (a common platform these days)
without CYGWIN you would have a lot of trouble. This does not make GIT a
worse choice. That it lacks in portability is a current concern that
should be weighed along with the rest of the issues such as ease of use,
productivity, integration with other valuable tools, parallel
development support (reliable merge tracking being a major factor here),
and offline capabilities.

I think what you missed was my statement that if package installs do not
exist for the majority of the platforms you intend people to develop
PostgreSQL on, then the SCM system you are considering is not mature or
enough, or supported well enough by the community, to be a good
candidate and there will be trouble down the road if the system that is
chosen goes into disrepair. Being able to compile from source is a
virtue shared by open source developers - but a requirement that it must
be compiled from source is not a virtue. If it must be compiled from
source, it means the product is not valuable enough to people to create
a demand for a binary install package. Nobody should be forced to
compile an SCM system from source in order to contribute to PostgreSQL.
That would be just silly.

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>